Re: spec2k comparison of gcc 4.1 and 4.2 on AMD K8
NUMA support did strike me as a possible cause. I thought that L2 caches on the Opteron communicated by I assume by your response the Opteron memory controller doesn't allow cache propagation, instead invalidates the cache entries read (assuming again the write entries are handled differently). Menezes, Evandro wrote: Honza, Well, rather than unstable, they seems to be more memory layout sensitive I would say. (the differences are more or less reproducible, not completely random, but independent on the binary itself. I can't think of much else than memory layout to cause it). I always wondered if things like page coloring have chance to reduce this noise, but I never actually got around trying it. You didn't mention the processors in your systems, but I wonder if they are dual-core. If so, perhaps it's got to do with the fact that each K8 core has its own L2, whereas C2 chips have a shared L2. Then, try preceding "runspec" with "taskset 0x02" to avoid the process from hopping between cores and finding cold caches (though the kernel strives to stick a process to a single core, it's not perfect). HTH
Re: Status of C++11 Move and Using Unique_Ptr
On 2020-03-01 4:28 p.m., Jonathan Wakely wrote: > On Sun, 1 Mar 2020 at 20:24, Nicholas Krause wrote: >> I'm not sure of the current status of the C++11 >> move > > We're in the middle of GCC 10's stage 4 and not doing anything like that now. > > As has been said several times, it's in scope for GCC 11, but not before. > Jonathan, Sorry my memory was a bit bad about that :(. I don't recall what C++ features we decided on limiting to as that was still under discussion. I would really like unique_ptr and stl library features like that. however I don't cecall if there was a discussion on allowing C++ STL 11 library features in gcc. At least it was not a definite yes on allowing STL libraries, Nick
Tests Failing On x86_64
Greetings all, I am getting failing tests when running with: make bootstrap make -k check The only code I am running is the below patch: >From 8c26b03c27912a367af52fd1e48eafb9b934fdf5 Mon Sep 17 00:00:00 2001 From: Nicholas Krause Date: Sun, 28 Oct 2018 22:23:35 -0400 Subject: [PATCH] Fix bug 86293 This fixes the bug on the gcc bugzilla with id, 86293. Basically a variable is undefined in certain build configuration scentarios and therefore must be enabled with the attribute marco and the flag, unused for it to avoid this build error. Signed-off-by: Nicholas Krause --- libitm/method-serial.cc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libitm/method-serial.cc b/libitm/method-serial.cc index e4804946a34..ab23d0b5660 100644 --- a/libitm/method-serial.cc +++ b/libitm/method-serial.cc @@ -306,7 +306,7 @@ GTM::gtm_thread::serialirr_mode () // We're already serial, so we don't need to ensure privatization safety // for other transactions here. gtm_word priv_time = 0; - bool ok = disp->trycommit (priv_time); + bool ok __attribute__((unused)) = disp->trycommit (priv_time); // Given that we're already serial, the trycommit better work. assert (ok); } -- 2.17.1 It seems to be failing in Running /home/nick/obdjir/../gcc/libatomic/testsuite/libatomic.c/c.exp ... as this is the last thing I see but it could be a mistake in my code or something else. It does build gcc find through so it seems to be tests failing that are not expected. Thoughts? Cheers, Nick
Fixing Bug Id 66074
Greetings all, I am wondering why this bug is only for the function reported: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66074 Seems there are lots of other functions in that file that could use the exact same optimization, would it be better to rewrite the file to use the void object pointer for all functions that can use a secondary version for that so this would touch the function, gcc_jit_result_get_global as an example as it looks similar enough i.e. same function arguments. Due to this I am assuming all non error functions in this file should be rewritten this. Thanks and I will send a patch if that's the case, Nick
Fixing Bug Id 66074
Greetings all, I am wondering why this bug is only for the function reported: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66074 Seems there are lots of other functions in that file that could use the exact same optimization, would it be better to rewrite the file to use the void object pointer for all functions that can use a secondary version for that so this would touch the function, gcc_jit_result_get_global as an example as it looks similar enough i.e. same function arguments. Due to this I am assuming all non error functions in this file should be rewritten this. Thanks and I will send a patch if that's the case, Nick
PING: Re: Fixing Bug Id 66074
On 2018-11-06 2:05 p.m., nick wrote: > Greetings all, > I am wondering why this bug is only for the function reported: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66074 > Seems there are lots of other functions in that file that could > use the exact same optimization, would it be better to rewrite > the file to use the void object pointer for all functions that > can use a secondary version for that so this would touch the > function, gcc_jit_result_get_global as an example as it looks > similar enough i.e. same function arguments. Due to this I am > assuming all non error functions in this file should be rewritten > this. > > Thanks and I will send a patch if that's the case, > Nick > Greetings all, I am not heard back on whether I should continue or this is the correct approach to fixing this bug. Thanks, Nick
Help Out with Gcc
Greetings All, I assume you get lots of these but I was wondering what's the areas where gcc needs help the most these days that are good for a new developer to gcc. The only other question I have is the gcc internal manual here up to date for gcc 8 or not? https://gcc.gnu.org/onlinedocs/gccint/index.html#SEC_Contents Thanks, Nick
Working on GCC Tuple Issues
Greetings All,
Seems the code has changed and may actually require a better fix than just the
functions
mentioned on this page, http://cplusplus.github.io/LWG/lwg-active.html#2899.
I am wondering if these are the functions or one of them firstly:
constexpr tuple(tuple<_UElements...>&& __in)
_Inherited(static_cast<_Tuple_impl<0, _UElements...>&&>(__in)) { }
and why not just do all rvalue functions that are like this for
all operators? Seems the spec is only mentioned a few functions
but noexpect on move is normally a good idea unless the C++
standard or the C++ library needs it for other template parsing
reasons.
Regards,
Nick
Re: [PATCH] Add missing noexpect causes in tuple for move functions
On 2018-12-01 10:32 a.m., Jonathan Wakely wrote: > On Fri, 30 Nov 2018 at 20:54, Nicholas Krause wrote: >> >> This adds the remainging noexcept causes required for this cause >> to meet the spec as dicussed last year and documented here: >> http://cplusplus.github.io/LWG/lwg-active.html#2899. > > This isn't "the spec", it's a proposed (but incorrect) resolution to a > defect in the standard. What it proposes may not fix the defect, but I > think it's an improvement to the std::tuple API anyway, and so I want > libstdc++ to implement it. "The spec" is the C++ standard, but it > explicitly allows implementations to add stronger > exception-specifications where a function is known not to throw. > > Thanks for the patch. Something this small could be accepted without a > copyright assignment, but as it seems like you're interested in > contributing more (which is great!) you should be aware of the legal > prerequisites for larger contributions (which also applies to several > small contributions, even if each one is trivial). See > https://gcc.gnu.org/contribute.html for details, and let me know if > you have any questions about that. > Jonathan, My only question remains is for copyright is it per patch or just one time. My other question is related to the noexcept parts and that either I or you should move and CC the other involed list i.e. the llibstdc++ list. Cheers, Nick
Re: [PATCH] Add missing noexpect causes in tuple for move functions
On 2018-12-02 11:53 a.m., David Edelsohn wrote: > On Sat, Dec 1, 2018 at 11:46 PM nick wrote: >> >> On 2018-12-01 10:32 a.m., Jonathan Wakely wrote: >>> On Fri, 30 Nov 2018 at 20:54, Nicholas Krause wrote: >>>> >>>> This adds the remainging noexcept causes required for this cause >>>> to meet the spec as dicussed last year and documented here: >>>> http://cplusplus.github.io/LWG/lwg-active.html#2899. >>> >>> This isn't "the spec", it's a proposed (but incorrect) resolution to a >>> defect in the standard. What it proposes may not fix the defect, but I >>> think it's an improvement to the std::tuple API anyway, and so I want >>> libstdc++ to implement it. "The spec" is the C++ standard, but it >>> explicitly allows implementations to add stronger >>> exception-specifications where a function is known not to throw. >>> >>> Thanks for the patch. Something this small could be accepted without a >>> copyright assignment, but as it seems like you're interested in >>> contributing more (which is great!) you should be aware of the legal >>> prerequisites for larger contributions (which also applies to several >>> small contributions, even if each one is trivial). See >>> https://gcc.gnu.org/contribute.html for details, and let me know if >>> you have any questions about that. >>> >> >> Jonathan, >> >> My only question remains is for copyright is it per patch or just one time. >> >> My other question is related to the noexcept parts and that either I or >> you should move and CC the other involed list i.e. the llibstdc++ list. > > You can submit one copyright assignment per patch ... if you're a masochist. > > The recommended approach is a single "Futures" copyright assignment > for all current and future patches. > > Thanks, David > It mentions on the page to just ask about copyright forms, so I am asking here for them before I just send them to the assign email address given. Nick
Re: Optimizing C++ Move Functions in Stl
On 2018-12-11 8:37 a.m., Jonathan Wakely wrote: > On 10/12/18 16:09 -0500, nick wrote: >> Greetings All, >> >> Sorry I was busy last week but did get my forms signed off for the >> required copyright assignment. Anyhow seems that the tuple and other >> classes mentioned aren't the only only ones that could do noexpect >> optimization either for all cases or some in the header files. >> >> I am proposing that I sent either a patch series or a patch per class >> that actually could use this extension of the standard including the >> string class I believe. >> >> Not sure if this is a good idea but have opening it from discussion >> for what classes should this touch in the std helper files, > > We'll consider any patches that add noexcept appropriately. > > It's not always worth doing though. For constructors it can matter, > because it can affect the result of the is_nothrow_xxx_constructible > traits, which can cause different code paths to be taken elsewhere in > the library. For arbitrary member functions it doesn't usually make a > difference. The compiler can already see that most inline functions > can't throw, and so can already optimize accordingly. > > I suggest a series of patches, split along sensible lines (i.e. don't > propose changes to unrelated types like std::basic_string and > std::atomic in the same patch, which is always good advice anyway). > > Be aware that GCC is in Stage 3 of its development cycle, and changes > like this which do not fix any bugs are probably going to have to wait > for the next Stage 1. See https://gcc.gnu.org/develop.html#stage1 for > more information. > > Sorry for keeping this thread open. The only nit about your above comments related to the inlining from assignment operators always is in the same boat if I understand you then. This is probably the only member operator exception but it's basically a constructor that returns something into another object so that's why. Anyhow I cced the gcc development list but other than easy hacks are there any thing you guys could use help with in stage 3?. I am assuming it's still another 2-3 months before the final gcc 9 release and the above work should be submitted, so let me know what's outstanding or needs help for moving along for the final gcc 9 release. Nick P.S. I was not aware of a TODO page for gcc 9 goals so if there is one as I googled for one but couldn't find it, please just share that instead.
Re: Optimizing C++ Move Functions in Stl
On 2018-12-12 10:24 a.m., Jonathan Wakely wrote: > On 12/12/18 17:17 +0200, Ville Voutilainen wrote: >> On Wed, 12 Dec 2018 at 17:14, nick wrote: >> >>> > I think there's an attempt to ascertain that mostly constructors and >>> > assignment operators need noexcept-fixes, >>> > because that noexcept-ness is directly trait-detectable. >>> > That would match my current understanding of the situation for at >>> > least pair and tuple. >>> > >>> >>> >>> Yes that's true. I was also asking about is there a TODO list for the >>> current release >>> of gcc 9 as Jonathan mentioned this work is a stage 1 fix or feature and >>> should wait >>> until gcc 10 stage 1 so was wondering what work is needed in the current >>> stage 3. >>> >>> Sorry for the confusion with the previous email and hopefully this makes >>> more sense, >> >> We don't have a specific TODO list for gcc 9. For general stuff, we have >> https://gcc.gnu.org/wiki/LibstdcxxTodo >> which is a bit out of date... > > I think he's asking about GCC in general, not just libstdc++. The > answer is that fixing bugs is appropriate for stage 3, so pick any > open bugs from Bugzilla. > > That's right I was asking about all of gcc. Sorry I thought I CCed the gcc devel list so no wonder so confused. Sorry, Nick
Not Sure about best way to fix the Null Pointer
Greetings All, I seem to have probably traced this bug down but am not sure what is the best way to fix it being new here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395#add_comment Seems the issue is in va_heap::reserve in vec.h as we aren't checking if v is equal to N like in vaheap::release. Seems a few odd to me that it's not checking that as it calculates a allocation afterwards and seems more than likely it crashes due to v being Null. I am assuming this is the proper fix but let me know if I am fixing something like the allocation is known to be good. Before the vec_prefix::calculate_allocation call do: if (v == NULL) return Thanks, Nick
Segfault Question
Greetings All, I was attempting to fix this bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395#add_comment and managed to track it down to expand_concept in constraint.cc. Seems that we are hitting this case in tsubst_expr for the NULL_TREE: if (t == NULL_TREE || t == error_mark_node) return t and we only check result for error_mark_node. Is error_mark_node equal to a NULL_TREE or is it something else? If not than it seems that we should change our check to: if (result == error_mark_node || result == NULL_TREE) and it seems that this is also not checked it the other callers so it should be fixed. Let me known if I am missing something, Nick
Re: Segfault Question
On 2018-12-17 10:23 a.m., Nathan Sidwell wrote: > On 12/17/18 10:11 AM, Jonathan Wakely wrote: > >> The second snippet is his suggested fix for the caller of tsubst_expr >> in expand_concept. That would have been a lot more helpful as a patch: >> >> --- a/gcc/cp/constraint.cc >> +++ b/gcc/cp/constraint.cc >> @@ -563,7 +563,7 @@ expand_concept (tree decl, tree args) >> ++processing_template_decl; >> tree result = tsubst_expr (def, args, tf_none, NULL_TREE, true); >> --processing_template_decl; >> - if (result == error_mark_node) >> + if (result == error_mark_node || t == NULL_TREE) >> return error_mark_node; >> >> /* And lastly, normalize it, check for implications, and save >> >> The point is that tsubst_expr can return NULL_TREE, we should check for it. > > Are there cases that tsubst_expr returns NULL when the incoming T is > non-null? I.e. I'm hypothesizing DEF is NULL already. > > nathan > Sorry about my miscommunication before it. As for Nathan's comment you could be right. But the bug reports two concept calls in gdb where only one crashes according to it. However I managed to track down the differences to this occurring with the seg fault caller: #45 0x008f3dfa in (anonymous namespace)::satisfy_associated_constraints (args=0x770ca4a0, ci=0x770ca3c0) at ../../gcc/gcc/cp/cp-tree.h:1446 versus without: #30 0x008f55f2 in (anonymous namespace)::tsubst_compound_requirement (in_decl=0x0, complain=0, args=0x770bfde8, t=0x770bf528) at ../../gcc/gcc/tree.h:3658 Don't know why this would cause issues: #define OMP_CLAUSE_PRIVATE_DEBUG(NODE) \ (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_PRIVATE)->base.public_flag) in gcc/tree.h on line 1448. Any ideas? Nick
Re: Segfault Question
On 2018-12-17 11:12 a.m., nick wrote: > > > On 2018-12-17 10:23 a.m., Nathan Sidwell wrote: >> On 12/17/18 10:11 AM, Jonathan Wakely wrote: >> >>> The second snippet is his suggested fix for the caller of tsubst_expr >>> in expand_concept. That would have been a lot more helpful as a patch: >>> >>> --- a/gcc/cp/constraint.cc >>> +++ b/gcc/cp/constraint.cc >>> @@ -563,7 +563,7 @@ expand_concept (tree decl, tree args) >>> ++processing_template_decl; >>> tree result = tsubst_expr (def, args, tf_none, NULL_TREE, true); >>> --processing_template_decl; >>> - if (result == error_mark_node) >>> + if (result == error_mark_node || t == NULL_TREE) >>> return error_mark_node; >>> >>> /* And lastly, normalize it, check for implications, and save >>> >>> The point is that tsubst_expr can return NULL_TREE, we should check for it. >> >> Are there cases that tsubst_expr returns NULL when the incoming T is >> non-null? I.e. I'm hypothesizing DEF is NULL already. >> >> nathan >> > > Sorry about my miscommunication before it. > As for Nathan's comment you could be right. But the bug reports > two concept calls in gdb where only one crashes according to it. > However I managed to track down the differences to this occurring with the > seg fault caller: > #45 0x008f3dfa in (anonymous > namespace)::satisfy_associated_constraints (args=0x770ca4a0, > ci=0x770ca3c0) at ../../gcc/gcc/cp/cp-tree.h:1446 > versus without: > #30 0x008f55f2 in (anonymous namespace)::tsubst_compound_requirement > (in_decl=0x0, complain=0, args=0x770bfde8, t=0x770bf528) at > ../../gcc/gcc/tree.h:3658 > > Don't know why this would cause issues: > #define OMP_CLAUSE_PRIVATE_DEBUG(NODE) \ > (OMP_CLAUSE_SUBCODE_CHECK (NODE, OMP_CLAUSE_PRIVATE)->base.public_flag) > > in gcc/tree.h on line 1448. Any ideas? > > Nick > I tried working on it more today and it seems that this make be wrong it call.c: for (ix = 1; args->iterate (ix, &arg); ++ix) tempvec->quick_push (arg); for add_candiates. I don't know why we aren't setting it like: tempvec->quick_push((*arg[ix])); If you would prefer I send a patch to show the proposed fix just let me known, Nick
Patch Resend
Greetings All, I was wondering as I sent a patch before the holidays if I should resend it as I did not get any replies. Thanks, Nick
Re: Patch Resend
On 2019-01-07 10:44 a.m., Jonathan Wakely wrote:
> On Mon, 7 Jan 2019 at 15:42, nick wrote:
>>
>> Greetings All,
>>
>> I was wondering as I sent a patch before the holidays if I should resend it
>> as I did not get any replies.
>
> Which patch? I don't see any patch from you that didn't get some replies.
>
Sorry this is what I was talking about it's a fix for a bad patch:
This fixes the bug id, 71176 to use the proper known
code print formatter type, %lu for size_t rather than
%d which is considered best pratice for print statements.
Signed-off-by: Nicholas Krause
---
fixincludes/fixincl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fixincludes/fixincl.c b/fixincludes/fixincl.c
index 6dba2f6e830..5b8b77a77f0 100644
--- a/fixincludes/fixincl.c
+++ b/fixincludes/fixincl.c
@@ -158,11 +158,11 @@ main (int argc, char** argv)
if (VLEVEL( VERB_PROGRESS )) {
tSCC zFmt[] =
"\
-Processed %5d files containing %d bytes\n\
+Processed %5d files containing %lu bytes\n\
Applying %5d fixes to %d files\n\
Altering %5d of them\n";
-fprintf (stderr, zFmt, process_ct, ttl_data_size, apply_ct,
+fprintf (stderr, zFmt, process_ct, (unsigned int long) ttl_data_size,
apply_ct,
fixed_ct, altered_ct);
}
#endif /* DO_STATS */
--
2.17.1
Nick
GSOC
Greetings All, I was interested in the following two projects from the wiki for this summer if possible, Parallelize compilation using threads and Make C/C++ not automatically promote memory_order_consume to memory_order_acquire. Thanks, Nick
Bug gives no stack trace on segfault
Greetings, I've been busy so this probably has been fixed in since I last worked on it: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 I was using these instructions to try and get a trace: https://www.gnu.org/software/gcc/bugs/segfault.html But nothing seems to be outputted and don't known if that's normal. Here is what I'm running the program with and I've enabled --enable-checking: gdb --args ./bin/g++ -v -da -Q -fconcepts test.cpp Cheers, Nick
Re: Bug gives no stack trace on segfault
On 2019-03-17 6:50 a.m., Jonathan Wakely wrote: > On Sun, 17 Mar 2019, 00:21 nick, wrote: > >> Greetings, >> >> I've been busy so this probably has been fixed in since I last worked on >> it: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 >> >> I was using these instructions to try and get a trace: >> https://www.gnu.org/software/gcc/bugs/segfault.html >> >> But nothing seems to be outputted and don't known if that's normal. Here >> is what I'm >> running the program with and I've enabled --enable-checking: >> >> gdb --args ./bin/g++ -v -da -Q -fconcepts test.cpp >> > > That is not what the instructions you linked to tell you to do. > > You need to run that command to find out how the g++ driver invokes the > cc1plus compiler, and then debug cc1plus, not g++. > Jonathan, Thanks I wasn't running them correctly it seems. I'm wondering after tracing it as this looks very odd to me but does this: if (tree prev = lookup_concept_satisfaction (tmpl, targs)) return prev; on line 2044 in gcc/cp/constraint.cc return a NULL_TREE if it's no found as that seems to be the case in the bug as it's the one place that is mostly after a very brief look at for the segfault. Nick
Warning in gcc/libiberty/dyn-string.c during build
Greetings all, I just got this in my build output: ar: `u' modifier ignored since `D' is the default (see `U') configure: WARNING: cannot check for properly working vsnprintf when cross compiling, will assume it's ok ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’: ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] strncpy (dest->s + pos, src, length); ^~~~ ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here 272 | int length = strlen (src); |^~~~ ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’: \ ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation] 280 | strncpy (dest->s + pos, src, length); | ^~~~ ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here 272 | int length = strlen (src); |^~~~ I've already looked through git blame and it seems this code was last touched in 2000. That warning seems to be new to gcc 8 after a little research so is this a rather old bug that was not found and very subtle or is this a mislabel. Seems to be a mislabel to me but I'm new to the code base so just thought I would ask. Cheers, Nick
Bugzilla ID 88395
Greetings, I was working on this bug here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 I don't know if this is correct but after tracing it seems that this is wrong: tree vars = tsubst (t, args, complain, in_decl); and T would be wrapped in the correct caller to avoid segaults in some cases. This is for tsubst_constraint_variables in gcc/cp/constraint.cc from the root source directory. If that is correct. I was wondering what of the PARM_X marcos is the one used to fix up and wrap the tree t correctly. Cheers, Nick
Re: [PATCH] Proposed patch to fix bug id, 89796 on bugzilla
On 2019-03-25 9:25 a.m., Jonathan Wakely wrote: > On Mon, 25 Mar 2019 at 12:39, Nicholas Krause wrote: >> >> Not sure if this is a correct fix to this bug found here: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but >> comments are welcome. If a backtrace is required please >> let me know. I am just sending it to the development list >> for review to make sure it's OK in terms of my understanding >> the code. > > That's what the gcc-patches list is for. > Sorry it was sent there too. Didn't know which list was the correct one for reviewing RFC patches. Nick
Re: [PATCH] Proposed patch to fix bug id, 89796 on bugzilla
On 2019-03-25 9:29 a.m., Jonathan Wakely wrote: > On Mon, 25 Mar 2019 at 13:26, nick wrote: >> >> >> >> On 2019-03-25 9:25 a.m., Jonathan Wakely wrote: >>> On Mon, 25 Mar 2019 at 12:39, Nicholas Krause wrote: >>>> >>>> Not sure if this is a correct fix to this bug found here: >>>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but >>>> comments are welcome. If a backtrace is required please >>>> let me know. I am just sending it to the development list >>>> for review to make sure it's OK in terms of my understanding >>>> the code. >>> >>> That's what the gcc-patches list is for. >>> >> >> Sorry it was sent there too. Didn't know which list was the correct one for >> reviewing RFC patches. > > https://gcc.gnu.org/lists.html > https://gcc.gnu.org/contribute.html#patches > Thanks Jonathan, As for the patch documentation I will change the changelog after it's been reviewed. I'm newer to the code so would prefer it to be known correct and then I will just send a a proper changelogged patch. Not that I normally wouldn't just would like to check the code first before I sent a proper patch. Nick
Re: Warning in gcc/libiberty/dyn-string.c during build
On 2019-03-25 3:45 p.m., Jeff Law wrote:
> On 3/25/19 10:39 AM, Martin Sebor wrote:
>> On 3/23/19 9:49 PM, nick wrote:
>>> Greetings all,
>>> I just got this in my build output:
>>> ar: `u' modifier ignored since `D' is the default (see `U')
>>> configure: WARNING: cannot check for properly working vsnprintf when
>>> cross compiling, will assume it's ok
>>> ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
>>> ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
>>> truncated before terminating nul copying as many bytes from a string
>>> as its length [-Wstringop-truncation]
>>> strncpy (dest->s + pos, src, length);
>>> ^~~~
>>> ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here
>>> 272 | int length = strlen (src);
>>> | ^~~~
>>> ../../gcc/libiberty/dyn-string.c: In function ‘dyn_string_insert_cstr’:
>>> \ ../../gcc/libiberty/dyn-string.c:280:3: warning: ‘strncpy’ output
>>> truncated before terminating nul copying as many bytes from a string
>>> as its length [-Wstringop-truncation]
>>> 280 | strncpy (dest->s + pos, src, length);
>>> | ^~~~
>>> ../../gcc/libiberty/dyn-string.c:272:16: note: length computed here
>>> 272 | int length = strlen (src);
>>> | ^~~~
>>>
>>> I've already looked through git blame and it seems this code was last
>>> touched in 2000. That warning seems
>>> to be new to gcc 8 after a little research so is this a rather old
>>> bug that was not found and very
>>> subtle or is this a mislabel. Seems to be a mislabel to me but I'm new
>>> to the code base so just thought
>>> I would ask.
>>
>> The warning detects strncpy calls that create unterminated string
>> copies. That can happen for example when the function is misused
>> by specifying a bound that's equal to the length of the source,
>> as in:
>>
>> void f (char *d, const char *s)
>> {
>> int n = strlen (s);
>> strncpy (d, s, n);
>> }
>>
>> But the warning is far from perfect and it cannot distinguish
>> all the incorrect misuses from the benign ones. For instance,
>> it triggers in the case below even though the copy is nul
>> terminated:
>>
>> void g (char *d, const char *s)
>> {
>> int n = strlen (s);
>> d[n] = 0;
>> strncpy (d, s, n);
>> }
> The dynamic case is painful :-)
>
>
>
>
>
>
>> In dyn_string_insert_cstr(), although the strnlen call itself
>> doesn't nul-terminate the copy (and so the warning isn't strictly
>> incorrect), the loop before the call does make sure the copy is
>> nul-terminated (similarly to function g above), and so the result
>> is a valid nul-terminated string.
> This reminds me a bit of some of the failure to eliminate dead stores
> problems that are in BZ as well as some of the uninit issues for memory
> references that's been rattling around in my head. It's also related
> to SRA. Richi has stated (and I tend to agree) there's a goodly amount
> of common analysis that can probably be shared across these problems.
>
> I don't know if there's a grand unifying analysis that will tackle all
> of this, but it certainly feels like there's at least something worth
> exploring in this space.
>
> Jeff
>
The easiest way forward for me is should I just use W=1 or something or
even better is just ctags and parse the calls in the parts you mentioned.
It's worth looking into as there may be longs of small callers that
actually really add up.
As for Martin don't know if I would be much help but if you want help with
the work on -nul-terimated let me known.
Cheers,
Nick
GSOC
Greetings All, I would like to take up parallelize compilation using threads or make c++/c memory issues not automatically promote. I did ask about this before but not get a reply. When someone replies I'm just a little concerned as my writing for proposals has never been great so if someone just reviews and doubt checks that's fine. As for the other things building gcc and running the testsuite is fine. Plus I already working on gcc so I've pretty aware of most things and this would be a great steeping stone into more serious gcc development work. If sample code is required that's in mainline gcc I sent out a trial patch for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 Cheers, Nick
Re: GSOC
On 2019-03-26 9:41 a.m., Richard Biener wrote:
> On Tue, 26 Mar 2019, David Malcolm wrote:
>
>> On Mon, 2019-03-25 at 19:51 -0400, nick wrote:
>>> Greetings All,
>>>
>>> I would like to take up parallelize compilation using threads or make
>>> c++/c
>>> memory issues not automatically promote. I did ask about this before
>>> but
>>> not get a reply. When someone replies I'm just a little concerned as
>>> my writing for proposals has never been great so if someone just
>>> reviews
>>> and doubt checks that's fine.
>>>
>>> As for the other things building gcc and running the testsuite is
>>> fine. Plus
>>> I already working on gcc so I've pretty aware of most things and this
>>> would
>>> be a great steeping stone into more serious gcc development work.
>>>
>>> If sample code is required that's in mainline gcc I sent out a trial
>>> patch
>>> for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395
>>>
>>> Cheers,
>>>
>>> Nick
>>
>> It's good to see that you've gotten as far as attaching a patch to BZ
>> [1]
>>
>> I think someone was going to attempt the "parallelize compilation using
>> threads" idea last year, but then pulled out before the summer; you may
>> want to check the archives (or was that you?)
>
> There's also Giuliano Belinassi who is interested in the same project
> (CCed).
>
>> IIRC Richard [CCed] was going to mentor, with me co-mentoring [2] - but
>> I don't know if he's still interested/able to spare the cycles.
>
> I've offered mentoring to Giuliano, so yes.
>
That was just there because it was assumed wrong by me. I sent a proposed
probably correct patch to the gcc patches list without a commit message
as I wanted to make sure it was correct first. This is the said patch:
>From a5fcad0cd1d1b79606ad9cec9a37d6a77ee50fc8 Mon Sep 17 00:00:00 2001
From: Nicholas Krause
Date: Sun, 24 Mar 2019 15:07:18 -0400
Subject: [PATCH] Proposed patch to fix bug id, 89796 on bugzilla
Not sure if this is a correct fix to this bug found here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89796 but
comments are welcome. If a backtrace is required please
let me know. I am just sending it to the development list
for review to make sure it's OK in terms of my understanding
the code.
Signed-off-by: Nicholas Krause
---
gcc/cp/constraint.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
index 9884eb0db50..a78d0a9a49b 100644
--- a/gcc/cp/constraint.cc
+++ b/gcc/cp/constraint.cc
@@ -1882,7 +1882,7 @@ tsubst_requires_expr (tree t, tree args,
tree parms = TREE_OPERAND (t, 0);
if (parms)
{
- parms = tsubst_constraint_variables (parms, args, complain, in_decl);
+ parms = tsubst_constraint_variables (PARM_CONSTR_PARMS (parms), args,
complain, in_decl);
if (parms == error_mark_node)
return error_mark_node;
}
--
2.17.1
>> That said, the parallel compilation one strikes me as very ambitious;
>> it's not clear to me what could realistically be done as a GSoC
>> project. I think a good proposal on that would come up with some
>> subset of the problem that's doable over a summer, whilst also being
>> useful to the project. The RTL infrastructure has a lot of global
>> state, so maybe either focus on the gimple passes, or on fixing global
>> state on the RTL side? (I'm not sure)
>
> That was the original intent for the experiment. There's also
> the already somewhat parallel WPA stage in LTO compilation mode
> (but it simply forks for the sake of simplicity...).
>
>> 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).
>
The GC would make the most sense I think in terms of making this better
as shared state would normally slow this down.
Nick
> The GC will be one obstackle. The original idea was to drive
> parallelization on the pass level by the pass manager for the
> GIMPLE passes, so serialization points would be in it.
>
> Richard.
>
>> Hope this is constructive/helpful
>> Dave
>>
>> [1] though typically our workflow involved sending patches to the gcc-
>> patches mailing list
>> [2] as libgccjit maintainer I have an interest in global state within
>> the compiler
>> [3] I posted some ideas about this back in 2013 IIRC; probably
>> massively bit-rotted since then. I also gave a talk at Cauldron 2013
>> about global state in the compiler (with a view to gcc-as-a-shared-
>> library); likewise I expect much of the ideas there to be out-of-date);
>> for libgccjit I went with a different approach
Re: GSOC
On 2019-03-27 9:55 a.m., Giuliano Belinassi wrote: > Hi, > > On 03/26, Richard Biener wrote: >> On Tue, 26 Mar 2019, David Malcolm wrote: >> >>> On Mon, 2019-03-25 at 19:51 -0400, nick wrote: >>>> Greetings All, >>>> >>>> I would like to take up parallelize compilation using threads or make >>>> c++/c >>>> memory issues not automatically promote. I did ask about this before >>>> but >>>> not get a reply. When someone replies I'm just a little concerned as >>>> my writing for proposals has never been great so if someone just >>>> reviews >>>> and doubt checks that's fine. >>>> >>>> As for the other things building gcc and running the testsuite is >>>> fine. Plus >>>> I already working on gcc so I've pretty aware of most things and this >>>> would >>>> be a great steeping stone into more serious gcc development work. >>>> >>>> If sample code is required that's in mainline gcc I sent out a trial >>>> patch >>>> for this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88395 >>>> >>>> Cheers, >>>> >>>> Nick >>> >>> It's good to see that you've gotten as far as attaching a patch to BZ >>> [1] >>> >>> I think someone was going to attempt the "parallelize compilation using >>> threads" idea last year, but then pulled out before the summer; you may >>> want to check the archives (or was that you?) >> >> There's also Giuliano Belinassi who is interested in the same project >> (CCed). > > Yes, I will apply for this project, and I will submit the final version > of my proposal by the end of the week. > > Currently, my target is the `expand_all_functions` routine, as most of > the time is spent on it according to the experiments that I performed as > part of my Master's research on compiler parallelization. > (-O2, --disable-checking) > > Thank you, > Giuliano. > > My goal was this: 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). So there is no conflict between me and Giuliano. Richard and me have already been going back and forth. The remaining tasks for me are just write the proposal as the big one and I asked Richard to sent me a example you guys liked. I've signed up to contribute for the last year so that's fine. Just letting the list known as well as Richard where I am, Nick >> >>> IIRC Richard [CCed] was going to mentor, with me co-mentoring [2] - but >>> I don't know if he's still interested/able to spare the cycles. >> >> I've offered mentoring to Giuliano, so yes. >> >>> That said, the parallel compilation one strikes me as very ambitious; >>> it's not clear to me what could realistically be done as a GSoC >>> project. I think a good proposal on that would come up with some >>> subset of the problem that's doable over a summer, whilst also being >>> useful to the project. The RTL infrastructure has a lot of global >>> state, so maybe either focus on the gimple passes, or on fixing global >>> state on the RTL side? (I'm not sure) >> >> That was the original intent for the experiment. There's also >> the already somewhat parallel WPA stage in LTO compilation mode >> (but it simply forks for the sake of simplicity...). >> >>> 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). >> >> The GC will be one obstackle. The original idea was to drive >> parallelization on the pass level by the pass manager for the >> GIMPLE passes, so serialization points would be in it. >> >> Richard. >> >>> Hope this is constructive/helpful >>> Dave >>> >>> [1] though typically our workflow involved sending patches to the gcc- >>> patches mailing list >>> [2] as libgccjit maintainer I have an interest in global state within >>> the compiler >>> [3] I posted some ideas about this back in 2013 IIRC; probably >>> massively bit-rotted since then. I also gave a talk at Cauldron 2013 >>> about global state in the compiler (with a view to gcc-as-a-shared- >>> library); likewise I expect much of the ideas there to be out-of-date); >>> for libgccjit I went with a different approach
GSOC Proposal
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. Any other comments are welcome as well as I write it there, Nick
GSOC initial Draft
Greetings All, Sorry about another message but seems it was better to write an initial draft for review here: https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit Please let me know what changes or clarity in wording you would like as I'm assuming it needs some changes including from Richard. Thanks, Nick
Re: GSOC Proposal
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. Nick >> Any other comments are welcome as well as I write it there, >> Nick
Re: GSOC Proposal
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 going, Nick > Richard. > >> Nick >>>> Any other comments are welcome as well as I write it there, >>>> Nick >> >
Re: GSOC Proposal
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
FIXME in gcc/gimplify.c
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
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: >
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_fu
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: 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_properti
Re: GSOC Proposal
On 2019-04-03 7:30 a.m., Richard Biener wrote: > On Mon, 1 Apr 2019, nick wrote: > >> >> >> On 2019-04-01 9:47 a.m., Richard Biener wrote: >>> On Mon, 1 Apr 2019, nick wrote: >>> >>>> Well I'm talking about the shared roots of this garbage collector core >>>> state >>>> data structure or just struct ggc_root_tab. >>>> >>>> But also this seems that this to be no longer shared globally if I'm not >>>> mistaken >>>> or this: >>>> static vec extra_root_vec; >>>> >>>> Not sure after reading the code which is a bigger deal through so I wrote >>>> my proposal not just asking which is a better issue for not being thread >>>> safe. Sorry about that. >>>> >>>> As for the second question injection seems to not be the issue or outside >>>> callers but just internal so phase 3 or step 3 would now be: >>>> Find internal callers or users of x where x is one of the above rather >>>> than injecting outside callers. Which answers my second question about >>>> external callers being a issue still. >>>> >>>> Let me know which of the two is a better issue: >>>> 1. struct ggc_root_tabs being shared >>>> 2.static vec extra_root_vec; as a shared heap or >>>> vector of root nodes for each type of allocation >>>> >>>> and I will gladly rewrite my proposal sections for that >>>> as needs to be reedited. >>> >>> I don't think working on the garbage collector as a separate >>> GSoC project is useful at this point. Doing locking around >>> allocation seems like a good short-term solution and if that >>> turns out to be a performance issue for the threaded part >>> using per-thread freelists is likely an easy to deploy >>> solution. >>> >>> Richard. >>> >> I agree but we were discussing this: >> 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). > > The process of collecting garbage is not the only issue (and that > very issue is easiest mitigated by collecting only at specific > points - which is what we do - and have those be serializing points). > The main issue is the underlying memory allocator (GCC uses memory > that is garbage collected plus regular heap memory). > >> In addition I moved my paper back to our discussion about garbage collector >> state with outside callers.Seems we really need to do something about >> my wording as the idea of my project in a nutshell was to figure >> out how to mark shared state by callers and inject it into the >> garbage collector letting it known that the state was not shared between >> threads or shared. Seems that was on the GSoc page and in our discussions >> the issue >> is marking outside code for shared state. If that's correct then my >> wording of outside callers is incorrect it should have been shared >> state between threads on outside callers to the garbage collector. >> If the state is that in your wording above then great as I understand >> where we are going and will gladly change my wording. > > I'm still not sure what you are shooting at, the above sentences do > not make any sense to me. > >> Also freelists don't work here as the state is shared at the caller's >> end which would need two major issues: >> 1. Locking on nodes of the >> freelists when two threads allocate at the same thing which can be a >> problem if the shared state is shared a lot >> 2. Locking allocation with >> large numbers of callers can starve threads > > First of all allocating memory from the GC pool is not the main > work of GIMPLE passes so simply serializing at allocation time might > work out. Second free lists of course do work. What you'd do is > have a fast path in allocation using a thread-local "free list" > which you can allocate from without taking any lock. Maybe I should > explain "free list" since that term doesn't make too much sense in > a garbage collector world. What I'd do is when a client thread > asks for memory of size N allocate M objects of that size but put > M - 1 on the client thread local "free list" to be allocated lock-free > from for the next M - 1 calls. Note that garbage collected memory > objects are only handed out in fixed chunks (powers of two plus > a few specia
GSOC Proposal on GENERIC level issues with threads
Richard, This is the link: https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit Seems that the function finalize_compilation_unit is a issue as it's the final function before the GIMPLE level. It seems to have lots of issues related to shared state if I'm understanding it correctly. In my proposal I'm assuming that it's the final GENERIC pass and should be fixed, this is due to even if the GIMPLE level is fixed we can only pass in shared state there which is still not a complete threaded pipeline through all three layers of GENERIC,GIMPLE and RTA. We would be bottle necked here and that seems to be a issue after reading the code. Let me know if this makes more sense to you as a proposal and feel free to ask questions if something doesn't make sense, Nick
Re: GSOC Proposal
On 2019-04-05 6:25 a.m., Richard Biener wrote: > On Wed, 3 Apr 2019, nick wrote: > >> >> >> On 2019-04-03 7:30 a.m., Richard Biener wrote: >>> On Mon, 1 Apr 2019, nick wrote: >>> >>>> >>>> >>>> On 2019-04-01 9:47 a.m., Richard Biener wrote: >>>>> On Mon, 1 Apr 2019, nick wrote: >>>>> >>>>>> Well I'm talking about the shared roots of this garbage collector core >>>>>> state >>>>>> data structure or just struct ggc_root_tab. >>>>>> >>>>>> But also this seems that this to be no longer shared globally if I'm not >>>>>> mistaken >>>>>> or this: >>>>>> static vec extra_root_vec; >>>>>> >>>>>> Not sure after reading the code which is a bigger deal through so I wrote >>>>>> my proposal not just asking which is a better issue for not being thread >>>>>> safe. Sorry about that. >>>>>> >>>>>> As for the second question injection seems to not be the issue or outside >>>>>> callers but just internal so phase 3 or step 3 would now be: >>>>>> Find internal callers or users of x where x is one of the above rather >>>>>> than injecting outside callers. Which answers my second question about >>>>>> external callers being a issue still. >>>>>> >>>>>> Let me know which of the two is a better issue: >>>>>> 1. struct ggc_root_tabs being shared >>>>>> 2.static vec extra_root_vec; as a shared heap or >>>>>> vector of root nodes for each type of allocation >>>>>> >>>>>> and I will gladly rewrite my proposal sections for that >>>>>> as needs to be reedited. >>>>> >>>>> I don't think working on the garbage collector as a separate >>>>> GSoC project is useful at this point. Doing locking around >>>>> allocation seems like a good short-term solution and if that >>>>> turns out to be a performance issue for the threaded part >>>>> using per-thread freelists is likely an easy to deploy >>>>> solution. >>>>> >>>>> Richard. >>>>> >>>> I agree but we were discussing this: >>>> 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). >>> >>> The process of collecting garbage is not the only issue (and that >>> very issue is easiest mitigated by collecting only at specific >>> points - which is what we do - and have those be serializing points). >>> The main issue is the underlying memory allocator (GCC uses memory >>> that is garbage collected plus regular heap memory). >>> >>>> In addition I moved my paper back to our discussion about garbage collector >>>> state with outside callers.Seems we really need to do something about >>>> my wording as the idea of my project in a nutshell was to figure >>>> out how to mark shared state by callers and inject it into the >>>> garbage collector letting it known that the state was not shared between >>>> threads or shared. Seems that was on the GSoc page and in our discussions >>>> the issue >>>> is marking outside code for shared state. If that's correct then my >>>> wording of outside callers is incorrect it should have been shared >>>> state between threads on outside callers to the garbage collector. >>>> If the state is that in your wording above then great as I understand >>>> where we are going and will gladly change my wording. >>> >>> I'm still not sure what you are shooting at, the above sentences do >>> not make any sense to me. >>> >>>> Also freelists don't work here as the state is shared at the caller's >>>> end which would need two major issues: >>>> 1. Locking on nodes of the >>>> freelists when two threads allocate at the same thing which can be a >>>> problem if the shared state is shared a lot >>>> 2. Locking allocation with >>>> large numbers of callers can starve threads >>> >>> First of all allocating memory from the GC pool is not the main >>> work of G
Re: GSOC Proposal
On 2019-04-07 5:31 a.m., Richard Biener wrote: > On April 5, 2019 6:11:15 PM GMT+02:00, nick wrote: >> >> >> On 2019-04-05 6:25 a.m., Richard Biener wrote: >>> On Wed, 3 Apr 2019, nick wrote: >>> >>>> >>>> >>>> On 2019-04-03 7:30 a.m., Richard Biener wrote: >>>>> On Mon, 1 Apr 2019, nick wrote: >>>>> >>>>>> >>>>>> >>>>>> On 2019-04-01 9:47 a.m., Richard Biener wrote: >>>>>>> On Mon, 1 Apr 2019, nick wrote: >>>>>>> >>>>>>>> Well I'm talking about the shared roots of this garbage >> collector core state >>>>>>>> data structure or just struct ggc_root_tab. >>>>>>>> >>>>>>>> But also this seems that this to be no longer shared globally if >> I'm not mistaken >>>>>>>> or this: >>>>>>>> static vec extra_root_vec; >>>>>>>> >>>>>>>> Not sure after reading the code which is a bigger deal through >> so I wrote >>>>>>>> my proposal not just asking which is a better issue for not >> being thread >>>>>>>> safe. Sorry about that. >>>>>>>> >>>>>>>> As for the second question injection seems to not be the issue >> or outside >>>>>>>> callers but just internal so phase 3 or step 3 would now be: >>>>>>>> Find internal callers or users of x where x is one of the above >> rather >>>>>>>> than injecting outside callers. Which answers my second question >> about >>>>>>>> external callers being a issue still. >>>>>>>> >>>>>>>> Let me know which of the two is a better issue: >>>>>>>> 1. struct ggc_root_tabs being shared >>>>>>>> 2.static vec extra_root_vec; as a shared >> heap or >>>>>>>> vector of root nodes for each type of allocation >>>>>>>> >>>>>>>> and I will gladly rewrite my proposal sections for that >>>>>>>> as needs to be reedited. >>>>>>> >>>>>>> I don't think working on the garbage collector as a separate >>>>>>> GSoC project is useful at this point. Doing locking around >>>>>>> allocation seems like a good short-term solution and if that >>>>>>> turns out to be a performance issue for the threaded part >>>>>>> using per-thread freelists is likely an easy to deploy >>>>>>> solution. >>>>>>> >>>>>>> Richard. >>>>>>> >>>>>> I agree but we were discussing this: >>>>>> 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). >>>>> >>>>> The process of collecting garbage is not the only issue (and that >>>>> very issue is easiest mitigated by collecting only at specific >>>>> points - which is what we do - and have those be serializing >> points). >>>>> The main issue is the underlying memory allocator (GCC uses memory >>>>> that is garbage collected plus regular heap memory). >>>>> >>>>>> In addition I moved my paper back to our discussion about garbage >> collector >>>>>> state with outside callers.Seems we really need to do something >> about >>>>>> my wording as the idea of my project in a nutshell was to figure >>>>>> out how to mark shared state by callers and inject it into the >>>>>> garbage collector letting it known that the state was not shared >> between >>>>>> threads or shared. Seems that was on the GSoc page and in our >> discussions the issue >>>>>> is marking outside code for shared state. If that's correct then >> my >>>>>> wording of outside callers is incorrect it should have been shared >>>>>> state between threads on outside callers to the garbage collector. >>>>>> If the state is that in your wording above then great as I >> understand >>>>>> where we are go
Re: GSOC Proposal
On 2019-04-08 3:29 a.m., Richard Biener wrote: > On Sun, 7 Apr 2019, nick wrote: > >> >> >> On 2019-04-07 5:31 a.m., Richard Biener wrote: >>> On April 5, 2019 6:11:15 PM GMT+02:00, nick wrote: >>>> >>>> >>>> On 2019-04-05 6:25 a.m., Richard Biener wrote: >>>>> On Wed, 3 Apr 2019, nick wrote: >>>>> >>>>>> >>>>>> >>>>>> On 2019-04-03 7:30 a.m., Richard Biener wrote: >>>>>>> On Mon, 1 Apr 2019, nick wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2019-04-01 9:47 a.m., Richard Biener wrote: >>>>>>>>> On Mon, 1 Apr 2019, nick wrote: >>>>>>>>> >>>>>>>>>> Well I'm talking about the shared roots of this garbage >>>> collector core state >>>>>>>>>> data structure or just struct ggc_root_tab. >>>>>>>>>> >>>>>>>>>> But also this seems that this to be no longer shared globally if >>>> I'm not mistaken >>>>>>>>>> or this: >>>>>>>>>> static vec extra_root_vec; >>>>>>>>>> >>>>>>>>>> Not sure after reading the code which is a bigger deal through >>>> so I wrote >>>>>>>>>> my proposal not just asking which is a better issue for not >>>> being thread >>>>>>>>>> safe. Sorry about that. >>>>>>>>>> >>>>>>>>>> As for the second question injection seems to not be the issue >>>> or outside >>>>>>>>>> callers but just internal so phase 3 or step 3 would now be: >>>>>>>>>> Find internal callers or users of x where x is one of the above >>>> rather >>>>>>>>>> than injecting outside callers. Which answers my second question >>>> about >>>>>>>>>> external callers being a issue still. >>>>>>>>>> >>>>>>>>>> Let me know which of the two is a better issue: >>>>>>>>>> 1. struct ggc_root_tabs being shared >>>>>>>>>> 2.static vec extra_root_vec; as a shared >>>> heap or >>>>>>>>>> vector of root nodes for each type of allocation >>>>>>>>>> >>>>>>>>>> and I will gladly rewrite my proposal sections for that >>>>>>>>>> as needs to be reedited. >>>>>>>>> >>>>>>>>> I don't think working on the garbage collector as a separate >>>>>>>>> GSoC project is useful at this point. Doing locking around >>>>>>>>> allocation seems like a good short-term solution and if that >>>>>>>>> turns out to be a performance issue for the threaded part >>>>>>>>> using per-thread freelists is likely an easy to deploy >>>>>>>>> solution. >>>>>>>>> >>>>>>>>> Richard. >>>>>>>>> >>>>>>>> I agree but we were discussing this: >>>>>>>> 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). >>>>>>> >>>>>>> The process of collecting garbage is not the only issue (and that >>>>>>> very issue is easiest mitigated by collecting only at specific >>>>>>> points - which is what we do - and have those be serializing >>>> points). >>>>>>> The main issue is the underlying memory allocator (GCC uses memory >>>>>>> that is garbage collected plus regular heap memory). >>>>>>> >>>>>>>> In addition I moved my paper back to our discussion about garbage >>>> collector >>>>>>>> state with outside callers.Seems we really need to do something >>>> about >>>>>>>> my wording as the idea of my project in a nutshell was to figure >>>>
Re: GSOC Proposal
On 2019-04-08 9:42 a.m., Richard Biener wrote: > On Mon, 8 Apr 2019, nick wrote: > >> >> >> On 2019-04-08 3:29 a.m., Richard Biener wrote: >>> On Sun, 7 Apr 2019, nick wrote: >>> >>>> >>>> >>>> On 2019-04-07 5:31 a.m., Richard Biener wrote: >>>>> On April 5, 2019 6:11:15 PM GMT+02:00, nick wrote: >>>>>> >>>>>> >>>>>> On 2019-04-05 6:25 a.m., Richard Biener wrote: >>>>>>> On Wed, 3 Apr 2019, nick wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 2019-04-03 7:30 a.m., Richard Biener wrote: >>>>>>>>> On Mon, 1 Apr 2019, nick wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2019-04-01 9:47 a.m., Richard Biener wrote: >>>>>>>>>>> On Mon, 1 Apr 2019, nick wrote: >>>>>>>>>>> >>>>>>>>>>>> Well I'm talking about the shared roots of this garbage >>>>>> collector core state >>>>>>>>>>>> data structure or just struct ggc_root_tab. >>>>>>>>>>>> >>>>>>>>>>>> But also this seems that this to be no longer shared globally if >>>>>> I'm not mistaken >>>>>>>>>>>> or this: >>>>>>>>>>>> static vec extra_root_vec; >>>>>>>>>>>> >>>>>>>>>>>> Not sure after reading the code which is a bigger deal through >>>>>> so I wrote >>>>>>>>>>>> my proposal not just asking which is a better issue for not >>>>>> being thread >>>>>>>>>>>> safe. Sorry about that. >>>>>>>>>>>> >>>>>>>>>>>> As for the second question injection seems to not be the issue >>>>>> or outside >>>>>>>>>>>> callers but just internal so phase 3 or step 3 would now be: >>>>>>>>>>>> Find internal callers or users of x where x is one of the above >>>>>> rather >>>>>>>>>>>> than injecting outside callers. Which answers my second question >>>>>> about >>>>>>>>>>>> external callers being a issue still. >>>>>>>>>>>> >>>>>>>>>>>> Let me know which of the two is a better issue: >>>>>>>>>>>> 1. struct ggc_root_tabs being shared >>>>>>>>>>>> 2.static vec extra_root_vec; as a shared >>>>>> heap or >>>>>>>>>>>> vector of root nodes for each type of allocation >>>>>>>>>>>> >>>>>>>>>>>> and I will gladly rewrite my proposal sections for that >>>>>>>>>>>> as needs to be reedited. >>>>>>>>>>> >>>>>>>>>>> I don't think working on the garbage collector as a separate >>>>>>>>>>> GSoC project is useful at this point. Doing locking around >>>>>>>>>>> allocation seems like a good short-term solution and if that >>>>>>>>>>> turns out to be a performance issue for the threaded part >>>>>>>>>>> using per-thread freelists is likely an easy to deploy >>>>>>>>>>> solution. >>>>>>>>>>> >>>>>>>>>>> Richard. >>>>>>>>>>> >>>>>>>>>> I agree but we were discussing this: >>>>>>>>>> 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). >>>>>>>>> >>>>>>>>> The process of collecting garbage is not the only issue (and that >>>>>>>>> very issue is easiest mitigated by collecting only at sp
C++ no except updates
Jonathan, I don't know what work is remaining in my ideas with inlining r value functions as you seemed to have already taken up and probably finished my ideas from reading the list. If you want help finishing it just send me a ToDO of since C++11 and C++20 classes have not been made noexcept for the move constructor and assignment operator. Thanks if possible, Nick
SSA Pressure Reduction
Andrew, I read through your notes briefly on this issue and if you want help I'm game for it. I assuming it's fixed not through as the gcc projects pages tend to me out of date in my experience. Nick
Re: SSA Pressure Reduction
On 2019-05-07 5:04 p.m., Andrew MacLeod wrote: > On 5/7/19 2:40 PM, nick wrote: >> Andrew, >> >> I read through your notes briefly on this issue and if you want help I'm >> game for it. >> I assuming it's fixed not through as the gcc projects pages tend to me out >> of date in >> my experience. >> >> Nick > Yeah, very old project and not really on the radar any more :-) > > Thanks for offering tho. > > Andrew > > I figured. The GCC pages seem to be very old of date will this so I will just ask you what is ongoing in the SSA layer for gcc itself. Thanks, Nick
Threads Support Documentation
Greetings All, I was unable to find in the official gcc internals manual but what layers have threaded support in terms of functions to use them. I'm not asking about implemented but at least a start to being implemented. Thanks, Nick
Writeup of Paralleling Work Still Outstanding
Richard, It seems to be that it would be best to writeup the remaining work for paralleling the compiler. I'm aware of most of it in the cgraph* files and others. However since I don't have write privileges it will be impossible for me to do it. It seems that the passes outside of the current expand_all_functions work are the GENERIC reading of files up to the RTL layer including certain passes. RTL may not need it due to most shared state being at the GENERIC and GIMPLE/pre RTL layers. Regards, Nick
RTL Layer Paralleling
Greetings All, After getting it some thought I've yet to see any real focus on making the RTL layers or just the architectural backends parallel in nature. Is there a reason for this as my assumption is that after reading parts of the x86 and rs6000 backend code it's not needed. This seems to be the case as most of the profiling only really shows bottle necking at least in my research at the gimple layer. Is this because little time has been put into researching the RTL passes or it's just assumed to have no requirements require to gimple and perhaps post GENERIC/pre GIMPLE passes? Just curious as I've not a RTL or backend expert, Nick
Outdated Documentation due to naming change of the function walk_dominator_tree
Greetings, In both the manual and general other places it seems that the old walk_dominator_tree is used instead of the current walk name. Trevor has been CCed as this change occurred it seems in 2013 but some of the callers including the manual are still out of date. Sending patches for fixing the code comments is fine and I don't mind but the manual itself also requires changes so making sure that gets changed as well. Thanks, Nick
Re: Outdated Documentation due to naming change of the function walk_dominator_tree
On 2019-06-07 10:36 p.m., nick wrote: > Greetings, > > In both the manual and general other places it seems that the old > walk_dominator_tree is used instead > of the current walk name. Trevor has been CCed as this change occurred it > seems in 2013 but some of > the callers including the manual are still out of date. > > Sending patches for fixing the code comments is fine and I don't mind but the > manual itself also requires > changes so making sure that gets changed as well. > > Thanks, > Nick > Sorry about the second email. Adding what is the correct email for Trevor currently. Nick
Re: Parallelize GCC with Threads -- First Evaluation
On 2019-06-24 8:59 a.m., Giuliano Belinassi wrote: > Hi, > > Parallelize GCC with Threads -- First Evaluation > > Hi everyone, > > I am attaching the first evaluation report here publicly for gathering > feedback. The file is in markdown format and it can be easily be converted to > PDF for better visualization. > > I am also open to suggestions and ideas in order to improve the current > project :-) > > My branch can be seen here: > https://gitlab.com/flusp/gcc/tree/giulianob_parallel > > Giuliano > Guiliano, Three things first your original proposal was just for expand_all_functions so don't know if it's extended out now but there's other parts in my research so the title was a little confusing. I'm assuming this is outside the scope of the current project but does your all_rtl_passes function help out with architecture specific tuning flags as it seems that my research states that's one area of shared state. In addition for memory this may be really hard to do but can you have a signaler that tells each phase what data to pass on therefore notifying what needs to be passed on to the next pass. So if expand_all_functions needs to pass x the signaler will notify the pass and just swap the values into the pass lock less if possible or just kill it off if not. This would mean writing a GENERIC to RTL final passes signaler which may take too long considering the scope of the project. Again that's just off the top of my head so it may be a really bad idea, Nick P.S. Good luck through.
Re: Parallelize GCC with Threads -- First Evaluation
On 2019-06-25 9:40 a.m., Giuliano Belinassi wrote: > Hi > > On 06/24, nick wrote: >> >> >> On 2019-06-24 8:59 a.m., Giuliano Belinassi wrote: >>> Hi, >>> >>> Parallelize GCC with Threads -- First Evaluation >>> >>> Hi everyone, >>> >>> I am attaching the first evaluation report here publicly for gathering >>> feedback. The file is in markdown format and it can be easily be converted >>> to >>> PDF for better visualization. >>> >>> I am also open to suggestions and ideas in order to improve the current >>> project :-) >>> >>> My branch can be seen here: >>> https://gitlab.com/flusp/gcc/tree/giulianob_parallel >>> >>> Giuliano >>> >> >> Guiliano, >> >> Three things first your original proposal was just for expand_all_functions >> so don't >> know if it's extended out now but there's other parts in my research so the >> title >> was a little confusing. > > Everything that I am doing is to parallelize this function. Notice that > in trunk there is a call to node->expand(), and in order to expand two > nodes in parallel I have to explore all shared states inside these, > including the passes. Also my work until now is focused in GIMPLE. > >> >> I'm assuming this is outside the scope of the current project but does your >> all_rtl_passes >> function help out with architecture specific tuning flags as it seems that >> my research >> states that's one area of shared state. > > Sorry, but I am not sure if I understeand what you meant. When splitting > all_passes into all_passes and all_rtl_passes, I didn't touch it and I > am assuming it is working as all tests except three which I told Richard > are passing. As for tuning flags, I documented a few of then but I am > currently ignoring it since I marked it as backend dependency. > Exactly that's fine, it's been part of my research these days when I've had time. If you pass the documentation of which backend passes are not getting touched still that would be great as I'm going to inspect those later this week probably. IPA as your finding out now and SSA lowering seem to have issues too so I'm going to look into through as well. >> >> In addition for memory this may be really hard to do but can you have a >> signaler >> that tells each phase what data to pass on therefore notifying what needs >> to be >> passed on to the next pass. So if expand_all_functions needs to pass x the >> signaler >> will notify the pass and just swap the values into the pass lock less if >> possible >> or just kill it off if not. This would mean writing a GENERIC to RTL final >> passes >> signaler which may take too long considering the scope of the project. > > I am assuming you are talking about the pass-pipeline approach Richi > recommended to avoid the per-pass global-states. I don't think a signal > is a good idea here as we can lose signals around if we are not careful > enough. What I would do is to use a producer-consumer queue on each > pass, passing the function to optimize and a struct whith everything the > pass needs. Or protect the global states with a binary semaphore: when the > pass is running, it decrements the semaphore, and increments it after it > works is done. When the previous pass wants to send information, I > decrement the semaphore, change the variables, and increment it again. > This is pretty similar of how a mutex work. > >> That was basically my idea fleshed out so it's fine now. >> Again that's just off the top of my head so it may be a really bad idea, >> >> Nick >> >> P.S. Good luck through. > Thank you, > Giuliano > Sorry for not being clearer, Nick
Re: Doubts regarding the _Dependent_ptr keyword
On 2019-07-01 8:59 p.m., Paul E. McKenney wrote:
> On Tue, Jul 02, 2019 at 05:58:48AM +0530, Akshat Garg wrote:
>> On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote:
>>
>>> On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan <
>>> ramana@googlemail.com> wrote:
>>>
>>>> On Tue, Jun 25, 2019 at 11:03 AM Akshat Garg wrote:
>>>>>
>>>>> As we have some working front-end code for _Dependent_ptr, What should
>>>> we do next? What I understand, we can start adding the library for
>>>> dependent_ptr and its functions for C corresponding to the ones we created
>>>> as C++ template library. Then, after that, we can move on to generating the
>>>> assembly code part.
>>>>>
>>>>
>>>>
>>>> I think the next step is figuring out how to model the Dependent
>>>> pointer information in the IR and figuring out what optimizations to
>>>> allow or not with that information. At this point , I suspect we need
>>>> a plan on record and have the conversation upstream on the lists.
>>>>
>>>> I think we need to put down a plan on record.
>>>>
>>>> Ramana
>>>
>>> [CCing gcc mailing list]
>>>
>>> So, shall I start looking over the pointer optimizations only and see what
>>> information we may be needed on the same examples in the IR itself?
>>>
>>> - Akshat
>>>
>> I have coded an example where equality comparison kills dependency from the
>> document P0190R4 as shown below :
>>
>> 1. struct rcutest rt = {1, 2, 3};
>> 2. void thread0 ()
>> 3. {
>> 4. rt.a = -42;
>> 5. rt.b = -43;
>> 6. rt.c = -44;
>> 7. rcu_assign_pointer(gp, &rt);
>> 8. }
>> 9.
>> 10. void thread1 ()
>> 11. {
>> 12.int i = -1;
>> 13.int j = -1;
>> 14._Dependent_ptr struct rcutest *p;
>> 15.
>> 16.p = rcu_dereference(gp);
>> 17.j = p->a;
>> 18. if (p == &rt)
>> 19.i = p->b; /*Dependency breaking point*/
>> 20. else if(p)
>> 21. i = p->c;
>> 22. assert(i<0);
>> 23. assert(j<0);
>> 24. }
>> The gimple unoptimized code produced for lines 17-24 is shown below
>>
>> 1. if (p_16 == &rt)
>> 2. goto ; [INV]
>> 3. else
>> 4.goto ; [INV]
>> 5.
>> 6. :
>> 7. i_19 = p_16->b;
>> 8. goto ; [INV]
>> 9.
>> 10. :
>> 11. if (p_16 != 0B)
>> 12.goto ; [INV]
>> 13. else
>> 14.goto ; [INV]
>> 15.
>> 16. :
>> 17. i_18 = p_16->c;
>> 18.
>> 19. :
>> 20. # i_7 = PHI
>> 21. _3 = i_7 < 0;
>> 22. _4 = (int) _3;
>> 23. assert (_4);
>> 24. _5 = j_17 < 0;
>> 25. _6 = (int) _5;
>> 26. assert (_6);
>> 27. return;
>>
>> The optimized code after -O1 is applied for the same lines is hown below :
>>
>> 1. if (_2 == &rt)
>> 2.goto ; [30.00%]
>> 3. else
>> 4.goto ; [70.00%]
>> 5.
>> 6. [local count: 322122547]:
>> 7. i_12 = rt.b;
>> 8. goto ; [100.00%]
>> 9.
>> 10. [local count: 751619277]:
>> 11. if (_1 != 0)
>> 12. goto ; [50.00%]
>> 13. else
>> 14.goto ; [50.00%]
>> 15.
>> 16. [local count: 375809638]:
>> 17. i_11 = MEM[(dependent_ptr struct rcutest *)_2].c;
>> 18.
>> 19.[local count: 1073741824]:
>> 20. # i_7 = PHI
>> 21. _3 = i_7 < 0;
>> 22. _4 = (int) _3;
>> 23. assert (_4);
>> 24. _5 = j_10 < 0;
>> 25. _6 = (int) _5;
>> 26. assert (_6);
>> 27. return;
>
> Good show on tracing this through!
>
>> Statement 19 in the program gets converted from i_19 = p_16->b; in line 7
>> in unoptimized code to i_12 = rt.b; in line 7 in optimized code which
>> breaks the dependency chain. We need to figure out the pass that does that
>> and put some handling code in there for the _dependent_ptr qualified
>> pointers. Passing simply -fipa-pure-const, -fguess-branch-probability or
>> any other option alone does not produce the optimized code that breaks the
>> dependency. But applying -O1, i.e., allowing all the optimizations does so.
>> As passes are applied in a certain order, we need to figure out upto what
>> passes, the code remains same and after what pass the dependency does not
>> holds. So, we need to check the translated code after every pass.
>>
>> Does this sounds like a workable plan for ? Let me know your thoughts. If
>> this sounds good then, we can do this for all the optimizations that may
>> kill the dependencies at somepoint.
>
> I don't know of a better plan.
>
> My usual question... Is there some way to script the checking of the
> translated code at the end of each pass?
>
> Thanx, Paul
>
I don't off the top of my head where the documentation is but writing a gcc
tool to inspect passes if one doesn't exist is the best way forward. A gcc
tool would be exposed to those internals but not sure if it's easy to do
that in the time frame due to the effort required by you or Akshat.
Cheers,
Nick
Profile Graph for GIMPLE optimizations in expand_all_functions and other passes
Giuliano, I asked for some documentation off you related to the RTL passes. Not sure if you are just hitting bottlenecks in all_rtl_passes or ipa_passes functions but it seems that the SSA trees and cfgloop.c and cfgloop.h files optimization passes would still be a issue. Particularly after the final GIMPLE and IPA passes it would be great to multi-thread and be able to walk the dominator trees multi-threaded. Not sure if you've looked as what seem to be issues here and was wondering if these are happening in your profiling still. GENERIC to GIMPLE may also be a issue in gimipfly but less than those. Again I understand if's out of scope but it would be great if you have a current profile graph that I can see. It would give me an idea of where to start working outside of the core GIMPLE optimizations passes your working on. Huge thanks and again good luck, Nick P.S. Don't worry if you don't it would just be nice to have and rewriting multi-threaded memory allocation is not easy and even more so with the shared state between compiler passes.
Contact from SSA expertise
Jeff, Who is the best person to contact for SSA expertise in GCC as I've started trying to figure out if it's possible to multi-thread and parallel the SSA dominator trees including insertion, walking and pushing to hardware registers during RTL allocation. Huge thanks, Nick
Help out/New to the Project
Greetings All, I am interested in helping out with the gcc project. I understand there is a bugzilla I can get started on but is there anything else in terms of things I should be reading outside the core docs in the git tree and the docs on the gnu web pages. Or is there anything you guys are currently working on that seems some help either testing or otherwise? Thanks for any answers, Nick
Weird warning when building gcc
Greetings All,
I am wondering if this is a warning worth looking into or is it just another
false postive:
/home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev’ may be used uninitialized
in this function [-Wmaybe-uninitialized]
if ((next = try_combine (insn, prev, NULL, NULL,
Maybe it's just me being new to the project but is the code for that literally
or also identical between this and the
one where CC0 register is directly used.
if (HAVE_cc0
&& JUMP_P (insn)
&& (prev = prev_nonnote_insn (insn)) != 0
&& NONJUMP_INSN_P (prev)
&& sets_cc0_p (PATTERN (prev)))
{
if ((next = try_combine (insn, prev, NULL, NULL,
&new_direct_jump_p,
last_combined_insn)) != 0)
goto retry;
FOR_EACH_LOG_LINK (nextlinks, prev)
if ((next = try_combine (insn, prev, nextlinks->insn,
NULL, &new_direct_jump_p,
last_combined_insn)) != 0)
goto retry;
}
Without CC0 register explict:
/* Do the same for an insn that explicitly references CC0. */
if (HAVE_cc0 && NONJUMP_INSN_P (insn)
&& (prev = prev_nonnote_insn (insn)) != 0
&& NONJUMP_INSN_P (prev)
&& sets_cc0_p (PATTERN (prev))
&& GET_CODE (PATTERN (insn)) == SET
&& reg_mentioned_p (cc0_rtx, SET_SRC (PATTERN (insn
{
if ((next = try_combine (insn, prev, NULL, NULL,
&new_direct_jump_p,
last_combined_insn)) != 0)
goto retry;
FOR_EACH_LOG_LINK (nextlinks, prev)
if ((next = try_combine (insn, prev, nextlinks->insn,
NULL, &new_direct_jump_p,
last_combined_insn)) != 0)
goto retry;
}
Maybe it's just me being new here. Further more, was wondering if ctags support
is there. I assume it's
there but was unable to find anything in the build or configuration pages when
building gcc. As these
are the only two lines that are different:
&& GET_CODE (PATTERN (insn)) == SET
&& reg_mentioned_p (cc0_rtx, SET_SRC (PATTERN (insn)))
Sorry if this a stupid question but it seems really weird to me,
Nick
Re: Weird warning when building gcc
On 2017-09-23 12:05 PM, Jeff Law wrote: > On 09/22/2017 08:25 PM, nick wrote: >> Greetings All, >> >> I am wondering if this is a warning worth looking into or is it just another >> false postive: >> >> /home/nick/gcc/gcc/combine.c:1316:8: warning: ‘prev’ may be used >> uninitialized in this function [-Wmaybe-uninitialized] >> if ((next = try_combine (insn, prev, NULL, NULL, >> >> Maybe it's just me being new to the project but is the code for that >> literally or also identical between this and the >> one where CC0 register is directly used. > Looks like a false positive to me. Without more details (host, target, > flags, cpp output) I can't be 100% sure why it triggers though. > > Flow sensitive warnings such as this are very sensitive to a variety of > low level target and IL details. > > > > Jeff > Jeff, Thanks specifically what low level details do you need. It's currently on a x86-64 bit ubuntu host. Was build with the stock gcc from the ubuntu 17.04 repos with W=2 for extra warnings. What do these lines do, anything outside of the normal setting marcos as they seem to me: && GET_CODE (PATTERN (insn)) == SET && reg_mentioned_p (cc0_rtx, SET_SRC (PATTERN (insn))) I am wondering what GET_CODE,SET_SRC, PATTERN marcos do plus the function called, reg_mentioned_P? If your able to just tell me where the functions are located or how do you enable ctags for all of gcc? That would just save me asking stupid questions. Is there a global setting like make ctags for doing this or you I have to do it manually. Thanks for the quick response, Nick
Re: Weird warning when building gcc
On 2017-09-24 10:10 AM, Eric Gallager wrote: > On Sat, Sep 23, 2017 at 12:34 PM, nick wrote: >> If your able to just tell me where the functions are located or how do you >> enable ctags for all of >> gcc? That would just save me asking stupid questions. Is there a global >> setting like make ctags for >> doing this or you I have to do it manually. >> >> Thanks for the quick response, >> >> Nick > > Also, for `make ctags` to work from the top level source directory, > this patch needs to be applied: > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html > (The patch is approved but the thread says I was still waiting on > commit access at the time; I have since received commit access, but my > ssh keys that allow me to commit are currently stuck on a failing hard > drive, so if someone else could commit for me, it'd be appreciated.) > Actually that patch has issues, line numbers have changed from your commit and is failing here due to that: @endif target-libffi .PHONY: configure-target-zlib maybe-configure-target-zlib maybe-configure-target-zlib: @if gcc-bootstrap error: patch failed: Makefile.in:47871 error: Makefile.in: patch does not apply Seems to be an issue that target-libffi is no longer at that line number, it was moved to 47919 on my current up to date of yesterday tree. Seems that branch is rather old i.e. last year for the mailing archives you sent me. Should I just rewrite the patch to work with current or something? Cheers, Nick
Ctags Patch Fails
Jeff, Actually that patch has issues, line numbers have changed from your commit and is failing here due to that: @endif target-libffi .PHONY: configure-target-zlib maybe-configure-target-zlib maybe-configure-target-zlib: @if gcc-bootstrap error: patch failed: Makefile.in:47871 error: Makefile.in: patch does not apply Seems to be an issue that target-libffi is no longer at that line number, it was moved to 47919 on my current up to date of yesterday tree. Seems that branch is rather old i.e. last year for the mailing archives you sent me. Should I just rewrite the patch to work with current or something? Cheers, Nick P.S. I already sent this but this should be in around thread. Sorry for polluting the ML.
Possible Bug Fix/No Reply on Bugzilla
Greetings All, I commented here a few names ago, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82230. Not to be a annoyance but I have a school assignment and would like someone to reply if it's correct or something. I am assuming it's probably wrong but any comment would be very helpful before I sent in a patch to the patches list to get merged for the fix. Take care, Nick
Re: Nested-Functions
On 2018-01-03 06:05 PM, Jonathan Wakely wrote: > On 3 January 2018 at 21:13, Alexsandr Yvarov wrote: >> Why would dont add it at GNU G++? > > Aren't C++ lambda expressions more powerful and flexible? > It depends actually, lambdas are consider the C++ standard of this. I am wondering what you mean Alexsandir and what is your use case as lambdas tryto solve this for most use cases of antonymous and nested functions. What are the requirements if any that lambdas don't meant and have you looked at the C++14/17 standard for them if your compiler supports it. What do you mean by nested functions actually as that means a lot of things in compiler or language development. Cheers, Nick
Re: Nested-Functions
On 2018-01-03 07:52 PM, Austin T wrote: > By nested functions, I'm assuming that means raw function definitions that > are valid inside a temporary scope of a function. If I'm not mistaken, > they're equivalent to C++ lambda expressions but just written in a syntactic > sugar syntax. > > Austin > That's the same thing actually if your going to name your lambda. What are the advantages of this newer syntax or feature. Do you have any examples? Nick > On Jan 3, 2018 2:44 PM, "nick" <mailto:xerofo...@gmail.com>> wrote: > > > > On 2018-01-03 06:05 PM, Jonathan Wakely wrote: > > On 3 January 2018 at 21:13, Alexsandr Yvarov wrote: > >> Why would dont add it at GNU G++? > > > > Aren't C++ lambda expressions more powerful and flexible? > > > > It depends actually, lambdas are consider the C++ standard of this. I am > wondering what > you mean Alexsandir and what is your use case as lambdas tryto solve this > for most use > cases of antonymous and nested functions. What are the requirements if > any that lambdas > don't meant and have you looked at the C++14/17 standard for them if your > compiler > supports it. > > What do you mean by nested functions actually as that means a lot > of things in compiler or language development. > > Cheers, > Nick > >
Kudos!
If this e-mail is not appropriate for either DL, then apologies in advance. I've used GCC for many years on and off and have always liked it. But today I couldn't help but smile while using it. Here's what I saw: main.cpp: In function 'int main(int, char**)': main.cpp:130:29: error: 'Baz' was not declared in this scope main.cpp:130:29: note: suggested alternative: In file included from main.cpp:4:0: Baz.h:208:8: note: 'Foo::Bar::Baz' make[1]: *** [obj/main.o] Error 1 I'm using GCC 4.7.2, so I realize this feature has been present for a while now. But something like this is really nice to see. It's the little bit of help that saves me 20 seconds of doing the tedious cross-referencing manually. I've also noticed improvements in build failure messages where they are more useful in helping me figure out the problem. So this e-mail is Kudos to the project's developers & contributors for a rockin' product! Keep up the good work! Nick
Surprising Behavior Comparing Floats
First, I know that floating point variables should not be compared "raw"
due to the way they're represented. But the behavior I'm seeing has me
surprised.
Here's a small repo example:
---
#include
using namespace std;
int main()
{
float f1(4.94f + 0.2f), f2(5.14f), f3(4.94f), f4(0.2f), f5(f3 + f4);
cout << "1) " << "5.14 < 5.14: " << (5.14 < 5.14) << endl;
cout << "2) " << f1 << " < " << f1 << ": " << (f1 < f1) << endl;
cout << "3) " << f2 << " < " << f2 << ": " << (f2 < f2) << endl;
cout << "4) " << f1 << " < " << f2 << ": " << (f1 < f2) << endl;
cout << "5) " << f2 << " < " << f1 << ": " << (f2 < f1) << endl;
cout << "6) " << f2 << " < " << (f3 + f4) << ": " << (f2 < (f3 + f4) )
<< endl;
cout << "7) " << f2 << " < " << f5 << ": " << (f2 < f5) << endl;
}
---
And here's the output from running it:
nick@nimble ~/test2 $ g++ FloatCompare.cpp && ./a.out
1) 5.14 < 5.14: 0
2) 5.14 < 5.14: 0
3) 5.14 < 5.14: 0
4) 5.14 < 5.14: 0
5) 5.14 < 5.14: 0
6) 5.14 < 5.14: 1
7) 5.14 < 5.14: 0
I'm very surprised by the result in #6. #7 seems to be doing the same
thing, except that it uses a local variable to hold the sum.
Here's my GCC version:
nick@nimble ~/test2 $ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/i686-pc-linux-gnu/gcc-bin/4.7.3/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.7.3/lto-wrapper
Target: i686-pc-linux-gnu
Configured
with: /var/tmp/portage/sys-devel/gcc-4.7.3-r1/work/gcc-4.7.3/configure
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --prefix=/usr
--bindir=/usr/i686-pc-linux-gnu/gcc-bin/4.7.3
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.3/include
--datadir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3
--mandir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3/man
--infodir=/usr/share/gcc-data/i686-pc-linux-gnu/4.7.3/info
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.7.3/include/g
++-v4 --with-python-dir=/share/gcc-data/i686-pc-linux-gnu/4.7.3/python
--enable-languages=c,c++,java --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --disable-nls
--enable-checking=release --with-bugurl=https://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.7.3-r1 p1.4, pie-0.5.5'
--enable-libstdcxx-time --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --disable-multilib
--disable-altivec --disable-fixed-point --with-arch=i686
--enable-targets=all --enable-libgomp --enable-libmudflap
--disable-libssp --disable-libquadmath --enable-lto --without-cloog
--without-ppl
Thread model: posix
gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5)
I also have GCC 4.8 on my system and the result is the same.
Is this expected behavior?
Best regards,
Nick
Re: Surprising Behavior Comparing Floats
On Sat, 2014-01-11 at 16:24 +0100, Marc Glisse wrote: > First, this is not an appropriate list for this question. gcc-help would > be better. Sorry about that--my e-mail auto completed the address and I wasn't paying enough attention. > Second, there are hundreds of places on the internet answering > this same question. > > > Is this expected behavior? > > Yes. Thanks for the quick reply.
Re: Surprising Behavior Comparing Floats
On Sat, 2014-01-11 at 15:24 +, Rob wrote: > On Sat, 11 Jan 2014, Nick wrote: > > I'm very surprised by the result in #6. #7 seems to be doing the same > > thing, except that it uses a local variable to hold the sum. > > Sounds to me like it could be related to excess precision - checkout the > -ffloat-store option. I don't see it on my machine either way, but I'm > on 4.7.2. Thank you very much! The -ffloat-store option not only addresses the behavior I'm seeing, but the information in the man page for this option gives me a great starting point for information about why it behaves that way. Best regards, Nick
Re: Fwd: Re: gcc 4.1.1 for mcore
Hi Alex, this is the error message I'm getting: /tmp/ccvk5vjH.s:38: Error: operand must be absolute in range 1..32, not 53 I run on a Linux machine with AMD CPU (x86_64). Ah yes this problem. I have encountered it too. Presumably you are using a 64-bit Linux ? If you build in a 32-bit environment you can work around this problem. I use this command line, suggested to me by Alex Oliva: CC="gcc -m32" CXX="g++ -m32" ABI="32" setarch i686 I have a fix for the problem now, but the build fails later on (in newlib and then libiberty) so you'll have to give me another day to look at the problem. Cheers Nick
Re: Fwd: Re: gcc 4.1.1 for mcore
Hi Alex, Right - you should be able to build the MCore port now. At least as far as newlib/libgloss/libiberty anyway. libstdc++-v3 does not build at the moment due to a problem unrelated to the 64-bit build OS issue, but I assume that this does not bother you. (You will need the latest gcc and binutils sources for this...) Cheers Nick
RFC: Extending --help
Hi Guys,
Last month I submitted a patch to add a new switch to gcc:
--print-optimizers. The idea of this switch was that it would only
display those switches that controlled optimizations, and that it
would show their current status (activated/not activated). Mark
Mitchell suggested that it would be better to integrate this feature
into the current --help switch, so here is my proposal:
I would like to extend the --help switch so that, optionally, it
takes a parameter describing what type of information is required:
--help Does exactly the same as before.
--help=target Displays target specific switches only.
--target-help now becomes an alias for this
switch.
--help=warningsDisplays switches that control warnings.
Displays switch status as described below.
--help=optimizers Displays switches that control optimizations.
Display switch status as described below.
--help={tool} Displays the --help output of the specified
tool (cpp, cc1, cc1plus, as, collect-ld, ld).
--help=pre-processor-symbols Displays all the symbols predefined
by the pre-processor. (Not sure if this option
will be popular. I like it because I can never
remember the magic incantation to get this
information emitted into the .i file, and
besides I do not want the information in a .i
file, I want it listed to stdout).
For the --help=warnings and --help=optimizers switch extra
information is also displayed about each switch. If the -Q switch
has been enabled earlier on the command line, then the descriptive
help text for each of the switches is displayed alongside the
switch. Otherwise the help text is omitted and instead an
indication is given as to whether the switch is currently enabled or
disabled. This information is sensitive to the position of the
--help=... switch on the command line, so that it is possible for
example to use:
gcc -O2 --help=optimizers
to find out which optimizations are active at -O2, or even:
gcc -O3 --help=optimizers > /tmp/O3-opts
gcc -O2 --help=optimizers > /tmp/O2-opts
diff /tmp/O2-opts /tmp/O3-opts | grep enabled
to find out which extra optimizations are enabled by the -O3 switch.
This enabled/disabled output will also be in a well defined format,
making it machine parsable. This is helpful for another project we
are working on - the automatic selection of the most effective
optimization options to compile any given particular application.
For switches which are not binary in nature, the current state of
the switch would be displayed.
What do you think ?
Cheers
Nick
Re: Why does linker fail to resolve dependencies within the same .a file?
Hi Christian, /usr/bin/c++ -fPIC "CMakeFiles/simpleIO.dir/main_IO.o" -o simpleIO -rdynamic -L/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++ -lGL -lglut -Wl,-Bstatic -luriVision -luriVision -Wl,-Bdynamic -Wl,-rpath,/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++ Note: Placing "-luriVision" twice on the command line next to each other like that will not actually gain you anything. The only reason to include a library more than once on a linker command line is if it contains symbols that are referenced by files that are placed after the first occurrence of the library on the command line. eg: foo.o -lbar baz.o -lbar The second "-lbar" is only needed if baz.o includes references to symbols that are defined in libbar.a which will not be pulled in when resolving the references made by foo.o. In function `uriVideoSources::ImageReader::getFrame(bool, uriBase::RasterImage*)': ImageReader.cpp:(.text+0x90): undefined reference to `uriVideoSources::ImageReader_gen::getFrame_(bool, uriBase::RasterImage*)' [EMAIL PROTECTED]:~$ nm --demangle /home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++/liburiVision.a | grep outputFrame As has already been pointed out you are greping for 'outputFrame' when the error message you have reported was for a missing 'getFrame_' symbol. I assume therefore that you are also getting error messages about a missing reference to 'outputFrame_' ? 002c T uriMovieEditing::ImageWriter::outputFrame(uriBase::RasterImage*) T uriMovieEditing::ImageWriter::outputFrame(uriBase::RasterImage*, bool) U uriMovieEditing::ImageWriter_gen::outputFrame_(uriBase::RasterImage*, bool) Which if the above assumption is correct means that the linker is right. uriMovieEditing does contain an unresolved reference to an outputFrame_ symbol. You will need to add whichever library or object file contains that symbol to the linker command line, and if it is a library that contains it, then it must come *after* -luriVision on the command line. Cheers Nick
Re: Why does linker fail to resolve dependencies within the same .a file?
Hi Christian, [I have restored the CC to gcc@gcc.gnu.org as there may be other people interested in this discussion]. foo.o -lbar baz.o -lbar The second "-lbar" is only needed if baz.o includes references to symbols that are defined in libbar.a which will not be pulled in when resolving the references made by foo.o. I'm not so sure that's true, because someone said that putting "bar.a" on the linker command line is pretty much identical in effect to listing, on the command line, the files that got bundled up into bar.a. So if bar.a is made up of x.o, y.o and z.o, and z.o contains a function that depends on a function in x.o, then I really do need to list bar.a twice in order to resolve that dependency. No? No. :-) A library is not, quite, the same thing as a bunch of object files. For one thing the linker *will* repeatedly search a library until no more undefined symbols can be resolved. So in your example x.o will be pulled into the link because it is needed to resolve a reference in z.o (which is presumably needed to resolve a reference from an object file earlier on in the linker command line). This is all described in the linker documentation as well. Have a look at the description of the linker command line option --start-group. I pasted an irrelevant example by accident, but I really am seeing the problem in question (I think). Here's the link command and my first error message from it: /usr/bin/c++ -fPIC "CMakeFiles/simpleIO.dir/main_IO.o" -o simpleIO -rdynamic -L/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++ -lGL -lglut -Wl,-Bstatic -luriVision -luriVision -Wl,-Bdynamic -Wl,-rpath,/home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++ /home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++/liburiVision.a(ImageReader.o): In function `uriVideoSources::ImageReader::getFrame(bool, uriBase::RasterImage*)': ImageReader.cpp:(.text+0x90): undefined reference to `uriVideoSources::ImageReader_gen::getFrame_(bool, uriBase::RasterImage*)' and here's the (hopefully) telling nm/grep statement: [EMAIL PROTECTED]:~$ nm --demangle /home/cjc/csc583-svn/uriVisionLib/trunk/Development/Source/C++/liburiVision.a | grep "uriVideoSources::ImageReader_gen::getFrame" U uriVideoSources::ImageReader_gen::getFrame_(bool) U uriVideoSources::ImageReader_gen::getFrame_(bool, uriBase::RasterImage*) Well this tells me that ...getFrame_(bool.uriBase::RasterImage*) is an *undefined* symbol referenced from inside liburiVision.a. (Hence the 'U' attribute as displayed by nm). Hence the linker is correct in complaining that it cannot resolve the reference and hence you do need to tell the linker where to find this symbol. Where do you think the ...getFrame_(bool.uriBase::RasterImage*) symbol is defined ? Cheers Nick
-fdump-translation-unit output and GPL
Hi, If I make a program that calls by command line the gcc executable with -fdump-translation-unit option and parses the dump output file, does it have to adhere to the GPL license ? If it doesn't have to adhere to the GPL license, how about if my program gets the dump output by a pipe or a socket ? Thanks in advance for your answers, Nick Rolins
Re: help regarding ld
Hi Aram, i am using the arm-elf-gcc compiler to generate the assembly code arm-elf-gcc -mthumb -S new.c after this i use the arm-elf-as for genrating machine code arm-elf-as new.s Note - these two steps could be combined into one by using the -c switch instead of the -S switch: arm-elf-gcc -mthumb -c new.c it produces one a.out file.. Note: Despite its name this "a.out" file is not an executable program it is just an object file that still needs to be linked. Naming the file a.out is a "feature" of the assembler. arm-elf-ld a.out produces error like arm-elf-ld: warning: cannot find entry symbol _start; not setting start address how do i type the correct command line option for this Try using gcc to control the entire process from compilation to final link, like this: arm-elf-gcc new.c Cheers Nick
Ada and ARM build assertion failure
I've been having some difficulty building Ada as a native compiler for an ARM-based target that I'm working on. The error is: ../../xgcc -B../../ -c -g -O2 -W -Wall -gnatpg -g -O1 -fno-inline \ a-except.adb -o a-except.o | 4.0.0 20050318 (prerelease) (arm-riscos-elf) Assert_Failure nlists.adb:296| | Error detected at a-exexpr.adb:85:9 This seems to be a reoccurance of PR5677. As I'm using a modified backend, I wanted to know whether other users are having this problem when building Ada for ARM targets. The only patch I apply to Ada is below. Any thoughts before I go barking up the wrong tree ? Regards, Nick. diff -x '*.orig' -x '*.rej' -uprN /home/nick/riscos-aof/masters/gcc-4.0/gcc/ada/s-auxdec.ads gcc-4.0/gcc/ada/s-auxdec.ads --- /home/nick/riscos-aof/masters/gcc-4.0/gcc/ada/s-auxdec.ads 2004-06-16 14:50:06.0 +0100 +++ gcc-4.0/gcc/ada/s-auxdec.ads2005-03-18 11:30:24.0 + @@ -283,7 +283,7 @@ pragma Elaborate_Body (Aux_DEC); end record; for Aligned_Word'Alignment use - Integer'Min (2, Standard'Maximum_Alignment); + Integer'Min (4, Standard'Maximum_Alignment); procedure Clear_Interlocked (Bit : in out Boolean;
Re: Ada and ARM build assertion failure
Geert Bosch wrote: On Mar 21, 2005, at 02:54, Nick Burrett wrote: This seems to be a reoccurance of PR5677. I'm sorry, but I can't see any way this is related, could you elaborate? Sorry, I completely misread the PR. It is not related. for Aligned_Word'Alignment use - Integer'Min (2, Standard'Maximum_Alignment); + Integer'Min (4, Standard'Maximum_Alignment); This patch is wrong, as it implicitly increases the size of Aligned_Word from 2 to 4 bytes: size is always a multiple of the alignment. OK, but if I don't apply the patch, GNAT complains that the alignment should be 4, not 2 and compiling ceases. However, it is really dubious you need to change this package, as it is only used for DEC Ada compatibility on VMS systems. OK, but all systems build it, as it is unconditionally defined in Makefile.rtl::GNATRTL_NONTASKING_OBJS And here it exists in a i686-linux build: [EMAIL PROTECTED] rts]$ ls -l s-aux* lrwxrwxrwx 1 nick nick 50 Mar 18 12:51 s-auxdec.adb -> /home/nick/riscos-elf/gcc-4.0/gcc/ada/s-auxdec.adb lrwxrwxrwx 1 nick nick50 Mar 18 12:51 s-auxdec.ads -> /home/nick/riscos-elf/gcc-4.0/gcc/ada/s-auxdec.ads -r--r--r-- 1 nick nick 19835 Mar 18 12:57 s-auxdec.ali -rw-rw-r-- 1 nick nick 32908 Mar 18 12:57 s-auxdec.o [EMAIL PROTECTED] rts]$ Nick.
Re: gcc with arm -vfp instructions
Hi Aram, i like to know whether gcc can generate vfp instructions.. This is a GCC question not a binutils question. Please ask it on the gcc mailing list: [EMAIL PROTECTED] if then, whether it will be supported on binutils and the gdb simulator The assembler and linker will support vfp instructions if they are generated by the compiler, or indeed if they are in hand written assembler source files. Cheers Nick
Re: Obsoleting more ports for 4.0.
Hi Kazu, > fr30 > > > The same justification as > >http://gcc.gnu.org/ml/gcc/2004-06/msg01113.html > > Nobody showed an interest in keeping this port. I would like to keep this port alive. I happen to know that Fujitsu are still involved with developing and marketing it and that they will be contributing patches for the gcc port at some point in the future. Cheers Nick
unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
I'm running into an ICE in the prerelease, that is proving to be very difficult in reducing to a small testcase. If I preprocess the source (via -E or -save-temps) the code successfully compiles. If I minimally change the source file in some ways(like adding a static integer in the global scope) the code compiles. I've been able to delete some lines from the source file that's triggering the bug, including some from within the function that is triggering the ICE, but I'm down to a point where I can't easily reduce it further, or even get it into a single source file. Does this bug look familiar? 20629 is ICEing in the same spot, but it looks like theirs was reproducible after preprocessing. Is there any more information that I provide that would be helpful? I've attached the command line, specs and a stacktrace from cc1plus. -nick /dept/rnd/vendor/gcc-4.0.0pre1-amd64/bin/g++ -fno-builtin -O2 -g -DHAVE_X86_64 -DHAVE_LITTLE_ENDIAN -DHAVE_BYTESWAP_H -DHAVE_64BIT_POINTER -DHAVE_VA_COPY -DHAVE_XINERAMA -DPLATFORM_LINUX -D_FILE_OFFSET_BITS=64 -DHAVE_STL_LIMITS -DHAVE_IOS_BASE -Drestrict=__restrict__ -DPLATFORM_LINUX_AMD64 -DPLATFORM=LINUX_AMD64 -DBUILD=LINUX_AMD64_GCC400pre1_OPT_DEBUG -DDISTRO_SUSE -DDISTRO=SUSE -DDISTRO_VERSION=91 -DNVIDIA_VERSION_6111 -DNVIDIA_VERSION=6111 -DGCC_VERSION_400pre1 -DNDEBUG -I/usr/share/doc/NVIDIA_GLX-1.0/include -I. -I/dept/rnd/home/nick/work/build-zeno2/SUSE_AMD64_GCC400pre1_OPT_DEBUG/include -I/usr/X11R6/include -c bug.C -o /dev/null bug.C: In member function 'void EzFleshMesh::buildNodeArrays()': bug.C:411: internal compiler error: in cp_tree_equal, at cp/tree.c:1552 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. > /dept/rnd/vendor/gcc-4.0.0pre1-amd64/bin/g++ -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.0.0-20050410/configure --enable-languages=c,c++ --prefix=/dept/rnd/vendor/gcc-4.0.0-20050410-amd64 --enable-threads Thread model: posix gcc version 4.0.0 20050410 (prerelease) #0 internal_error (msgid=0x847cb2 "in %s, at %s:%d") at ../../gcc-4.0.0-20050410/gcc/diagnostic.c:496 #1 0x005640fc in fancy_abort (file=Variable "file" is not available. ) at ../../gcc-4.0.0-20050410/gcc/diagnostic.c:556 #2 0x00473171 in cp_tree_equal (t1=0x2a9a1c94b0, t2=0x2a9a1cbb90) at ../../gcc-4.0.0-20050410/gcc/cp/tree.c:1552 #3 0x00473198 in cp_tree_equal (t1=0x2a9a013820, t2=0x2a9a031460) at ../../gcc-4.0.0-20050410/gcc/cp/tree.c:1543 #4 0x004590b3 in comptypes (t1=0x2a9a00ea90, t2=0x2a9a02bdd0, strict=Variable "strict" is not available. ) at ../../gcc-4.0.0-20050410/gcc/cp/typeck.c:912 #5 0x00458ede in comptypes (t1=0x2a9a00ec30, t2=0x2a9a032000, strict=0) at ../../gcc-4.0.0-20050410/gcc/cp/typeck.c:1034 #6 0x0047b0b9 in cxx_types_compatible_p (x=0x2a9a00ec30, y=0x2a9a032000) at ../../gcc-4.0.0-20050410/gcc/cp/cp-objcp-common.c:173 #7 0x007776bd in expressions_equal_p (e1=0x2a9a1c9640, e2=0x2a9a1cbd20) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:127 #8 0x007776f7 in val_expr_pair_expr_eq (p1=0xc16b90, p2=0xcd25e0) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:153 #9 0x007ffcba in htab_find_slot_with_hash (htab=0xca98a0, element=0x81c3b9, hash=8504885, insert=INSERT) at ../../gcc-4.0.0-20050410/libiberty/hashtab.c:660 #10 0x0077794f in vn_add (expr=0x2a9a1cbd20, val=0x2a9a240330, vuses=0x0) at ../../gcc-4.0.0-20050410/gcc/tree-vn.c:199 #11 0x004e09c1 in execute_pre (do_fre=0 '\0') at ../../gcc-4.0.0-20050410/gcc/tree-ssa-pre.c:1742 #12 0x004c0802 in execute_pass_list (pass=0xa10b80) at ../../gcc-4.0.0-20050410/gcc/tree-optimize.c:533 #13 0x004c0825 in execute_pass_list (pass=0xa10700) at ../../gcc-4.0.0-20050410/gcc/tree-optimize.c:571 #14 0x004c0a66 in tree_rest_of_compilation (fndecl=0x847cb2) at ../../gcc-4.0.0-20050410/gcc/tree-optimize.c:668 #15 0x0046e690 in expand_body (fn=0x2a99e450d0) at ../../gcc-4.0.0-20050410/gcc/cp/semantics.c:2981 #16 0x0076ce74 in cgraph_expand_function (node=0x2a9a032a90) at ../../gcc-4.0.0-20050410/gcc/cgraphunit.c:835 #17 0x0076d0fa in cgraph_optimize () at ../../gcc-4.0.0-20050410/gcc/cgraphunit.c:1706 #18 0x00441a15 in cp_finish_file () at ../../gcc-4.0.0-20050410/gcc/cp/decl2.c:3053 #19 0x004a4f4a in c_common_parse_file (set_yydebug=Variable "set_yydebug" is not available. ) at ../../gcc-4.0.0-20050410/gcc/c-opts.c:1099 #20 0x0072fcc8 in toplev_main (argc=Variable "argc" is not available. ) at ../../gcc-4.0.0-20050410/gcc/toplev.c:998 #21 0x002a95688e5d in __libc_start_main () from /lib64/tls/libc.so.6 #22 0x0040258a in _start () at ../sysdeps/x86_64/elf/start.S:96
Re: unreducable cp_tree_equal ICE in gcc-4.0.0-20050410
On Thu, 14 Apr 2005, Dale Johannesen wrote: > On Apr 14, 2005, at 7:14 AM, Andrew Pinski wrote: > >>Does this bug look familiar? 20629 is ICEing in the same spot, but > >>it looks like theirs was reproducible after preprocessing. Is there > >>any more information that I provide that would be helpful? I've > >>attached the command line, specs and a stacktrace from cc1plus. > > > >I think this was fixed on the mainline by: > >2005-03-18 Dale Johannese <[EMAIL PROTECTED]> > > > >* cp/tree.c (cp_tree_equal): Handle SSA_NAME. > > Yep, and I didn't put it in the release branch. Bad Dale. OK to do > that? > > If this is the same problem, changing the VN hashtable size to 1 > should make it show up reproducibly. > The released 4.0.0 successfully compiles the code that was having problems before. -nick
tree-ssa-address ICE
The inclusion of this patch:
2005-06-07 Zdenek Dvorak <[EMAIL PROTECTED]>
* tree-ssa-address.c: New file.
* Makefile.in (tree-ssa-address.o): Add.
* expr.c (expand_expr_real_1): Do not handle REF_ORIGINAL on
INDIRECT_REFs. Handle TARGET_MEM_REFs.
...
causes an ICE when compiling the following code for the ARM/Thumb
instruction set:
int
foo (char *s1, char *s2, int size)
{
while (size > 0)
{
char c1 = *s1++, c2 = *s2++;
if (c1 != c2)
return c1 - c2;
size--;
}
return 0;
}
$ ../configure --target=arm-elf-linux --enable-languages=c
$ ./cc1 -quiet test.c -mthumb -O2
../../bug.c: In function ‘foo’:
../../bug.c:3: internal compiler error: in create_mem_ref, at
tree-ssa-address.c:585
Please submit a full bug report,
Nick.
Assembling pending decls before writing their debug info
Hi Guys,
There is a problem with unit-at-a-time compilation and DWARF debug
info generation. Consider this small test case which has been
derived from GDB's observer.c source file:
int observer_test_first_observer = 0;
int observer_test_second_observer = 0;
int observer_test_third_observer = 0;
void observer_test_first_notification_function (void)
{
observer_test_first_observer++;
}
void observer_test_second_notification_function (void)
{
observer_test_second_observer++;
}
void observer_test_third_notification_function (void)
{
observer_test_third_observer++;
}
When compiled with the current mainline gcc sources for an x86
native target and with "-g -O2 -dA" on the command line the
following debug info is produced:
[snip]
.long .LASF0 # DW_AT_name: "observer_test_first_observer"
.byte 0x1 # DW_AT_decl_file
.byte 0x1 # DW_AT_decl_line
.long 0x37# DW_AT_type
.byte 0x1 # DW_AT_external
.byte 0x5 # DW_AT_location
.byte 0x3 # DW_OP_addr
.long observer_test_first_observer
.uleb128 0x3# (DIE (0x37) DW_TAG_base_type)
.ascii "int\0" # DW_AT_name
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.uleb128 0x4# (DIE (0x3e) DW_TAG_variable)
.long .LASF1 # DW_AT_name: "observer_test_second_observer"
.byte 0x1 # DW_AT_decl_file
.byte 0x2 # DW_AT_decl_line
.long 0x37# DW_AT_type
.byte 0x1 # DW_AT_external
.byte 0x0 # DW_AT_const_value
[snip]
Note how observer_test_first_observer is correctly defined as having
a DW_AT_location and a DW_OP_addr whereas
observer_test_second_observer is incorrectly defined as having a
DW_AT_const_value. ie the debug info is saying that it is a
variable without a location in memory.
The reason for this behaviour is that the debug information is being
written out before the variables have been fully resolved. In
particular DECL_SET() for the second and third observer functions is
NULL when the debug info is generated, which is why they are being
given the DW_AT_const_value attribute.
In trying to solve this I found that switching the order of the
calls to lang_hooks.decls.final_write_globals() and
cgraph_varpool_assemble_pending_decls() in compile_file() worked,
and this seemed to be intuitively correct. But when I reran the gcc
testsuite I found that the change introduced a regression:
gcc.dg/varpool-1.c now had the variable
"unnecessary_static_initialized_variable" still defined at the end
of compilation.
I have investigated some more but not gotten much further, so I am
asking for help. Can anyone suggest where the conflict between
generating the debug info and deciding if the variable is going to
be emitted should really be resolved ?
Cheers
Nick
Re: Any plan to support Windows/x86-64?
Hi H. J. Is there any plan to support Windows/x86-64? No and yes. I think that we would like to support this target, but we just need contributers to work on it. (I am pretty sure that some people are working on it, but they may not be ready to contribute yet). What are needed for the port? Support for the 64-bit PE file format I guess. Cheers Nick
June 2015 GNU Toolchain Update
Hi Guys,
In this month's news we have:
* GCC now supports a "noplt" function attribute. This specifies
that the annotated function should not be called via the PLT
mechanism.
* GCC now supports a "target ()" function attribute to
enable target specific options on individual functions. The ARM
port now uses this mechanism to allow programmers to individually
specify whether a function should use ARM or THUMB instructions.
For example:
int foo __attribute__((target("thumb")));
Any functions inlined into the attributed function will inherit
that function's attributes.
* GCC now supports attributes on enums values, although only one
such attribute is currently available:
enum E {
oldval __attribute__((deprecated)),
newval
};
The deprecated attribute results in a warning if the enumerator
value is used anywhere in the source file. This is useful when
identifying enumerators that are expected to be removed in a
future version of a program.
* GCC now supports a new warning option: -Wlto-type-mismatch
During the link-time optimization the compiler will issue warnings
about type mismatches between duplicate global declarations found
in different compilation units. This option is enabled by default
when LTO optimization is being performed.
* The ARM port of GCC now recognises the ARMv8,1 architecture
extensions including the Large System Extension instructions,
Privileged Access Never, Limited Ordering Regions and Advanced
SIMD instructions.
* In GDB support for process record-replay and reverse debugging on
AArch64 targets has been added.
* Also in GDB support for Sun's version of the "stabs" debug file
format has been removed.
* The linker has a new command line option: -print-memory-usage
This makes the linker print out the used size and total size of
each memory region specified by the link script and used by the
executable, which can be helpful to programmers trying to squeeze
every last byte out of a particularly small region. The output
has a fixed format which is human readable and machine parsable.
For example:
Memory region Used Size Region Size %age Used
ROM:256 KB 1 MB 25.00%
RAM: 32 B 2 GB 0.00%
* The assembler and linker now support the compact exception handler
sections as used by MIPS toolchains. The new gas pseudo ops:
.cfi_personality_id
.cfi_fde_data[ ,...]
.cfi_inline_lsda []
Are provided to help specify the contents of this new type of
section.
* The assembler has a new option to enable section name substitution:
--sectname-subst
If enabled then section names may include the "%S" sequence which
will be substituted for the name of the current section. For
example:
.macro gen_exceptions
.section %S.exception
[...]
.previous
.endm
.text
[...]
gen_exceptions
[...]
.section .init
[...]
gen_exceptions
[...]
This will create four sections: .text, .text.exception, .init and
.init.exception. In the future other substitution sequences in
addition to %S may be provided.
* Support for the ARMv8.1 architecture has been added to the AArch64
and ARM ports. This includes support for the Adv.SIMD, LOR and
PAN architecture extensions.
Cheers
Nick
July/August GNU Toolchain update
Hi Guys,
Sorry for the delay in bringing you this update; I have been very
busy in the last few months. Anyway the highlights of the changes
to the GNU Toolchain are as follows:
* The GDB 7.10 branch has been created. Expect a release soon.
* Support for tracepoints on aarch64-linux was added in GDBserver.
* A point update of the FSF Binutils - 2.25.1 - has been released.
No new features but lots of important bug fixes.
* GCC 5.2 has been released. This is a bug-fix update to the
previous 5.1 release.
* The linker now has experimental support for the removal of
redundant sections from COFF and PE format files. This is
enabled via the --gc-sections linker command line option.
* A new linker command line option --require-defined= has
been added. This behaves in much the same way as the
--undefined= option in that it creates a reference to an
undefined symbol that should force a library to be pulled into
the link or garbage collection not to remove a specific section.
The difference between --require-defined and --undefined is that
with the former the linker will issue an error message if the
specified symbol has not been defined by the end of the link.
* The --disassemble (or -d) and --disassemble-all (or -D) options to
objdump have received a subtle change. With -d objdump will
assume that any symbols present in a code section occur on the
boundary between instructions and so it will refuse to disassemble
across such a boundary. With -D however this assumption is
suppressed. This means that it is possible for the output of
-d and -D to differ if, for example, data is stored in a code
section.
* GCC has a couple of new warning options available:
-Wframe-address
This generates a warning when the __builtin_frame_address or
__builtin_return_address are called with an argument greater than
0. Such calls may return indeterminate values or crash the
program.
-Wtautological-compare
This generates a warning if a self-comparison always evaluates to
true or false. This detects various mistakes such as:
int i = 1;
if (i > i) { ... }
* With the Nios II port of GCC it is now possible to specify the
target architecture variant with -march=r1 or -march=r2. It is
also possible to explicitly enable or disable the use of the r2
BMX (bit manipulation) and CDX (code density) instructions via the
use of the new -mbmx -mno-bmx -mcdx and -mno-cdx options.
Cheers
Nick
September 2015 GNU Toolchain Update
d' will silently discard any and
all orphan sections.
* The new PowerPC64 specific linker command line option
--no-save-restore-funcs tells the linker not to provide the
out-of-line register save and restore functions used by -Os compiled
code. The default is to provide any such referenced function for
a normal final link, but not do so for a relocatable link.
* The GAS assembler now supports symbol and label names that are
enclosed in double quotes ("). This allows them to contain
characters that are not part of valid symbol names in high level
languages.
* The STRINGS program has a new command line option
--output-separator= to provide a character or sequence of
characters to be used as separators between the strings that are
emitted.
* GDB 7.10 has been released.
GDB 7.10 brings new targets, features and improvements, including:
+ Improved support for accessing shared libraries directly from
the target system when debugging remotely.
+ Various Guile and Python scripting improvements, including (but not
limited to):
** Support for auto-loading Python/Guile scripts contained
in a special section named `.debug_gdb_scripts'.
** Support for writing a frame unwinder in Python.
+ Support for record-replay and reverse debugging on Aarch64 Linux.
+ GDB now has support for fork events on extended-remote Linux targets
(Linux kernels 2.5.60 and later).
+ Support for DTrace USDT (Userland Static Defined Tracing) probes
on x86_64 GNU/Linux targets.
+ Vector ABI support on S/390 GNU/Linux targets.
+ GDB now reads the GDBHISTSIZE environment variable rather than
HISTSIZE to determine the size of GDB's command history.
+ Support for setting the parity when connecting to the target
using a serial interface.
+ It is now possible to limit the number of candidates to be
considered during completion.
+ Support for Sun's version of the "stabs" debug file format
has been removed.
+ Support for the following targets and native configurations has
been removed:
** HP/PA running HP-UX (hppa*-*-hpux*)
** Itanium running HP-UX (ia64-*-hpux*)
Support for the "-xdb" command-line switch (HP-UX XDB compatibility
mode) has also been removed.
Cheers
Nick
PS. The monthly gcc/g++ DG tests show little change this time around:
GCC/DG unexpected failures
--
Aug'15 Sep'15
arm-eabi4 4
bfin-elf11 12
frv-elf 541 24
h8300-elf 71 71
iq2000-elf 684 687
m32r-elf- 9
mcore-elf 519 517
mipsisa32-elf 25 24
mipsisa64-elf 26 25
mn10300-elf 468 12
msp430-elf 100 559
powerpc-eabispe 15 15
rl78-elf99 99
rx-elf 42 41
sh-elf 6 6
v850e-elf 31 31
x86_64-pc-linux-gnu 2 2
G++/DG unexpected failures
--
Aug'15 Sep'15
arm-eabi35 35
bfin-elf23 23
frv-elf - 124
h8300-elf 294 297
iq2000-elf 32963336
m32r-elf- 102
mcore-elf 2221
mipsisa32-elf 926 923
mipsisa64-elf 926 926
mn10300-elf - 74
msp430-elf 10502449
powerpc-eabispe 135 150
rl78-elf- 884
rx-elf 50 50
sh-elf 35 35
v850e-elf - 94
x86_64-pc-linux-gnu 17 17
Re: September 2015 GNU Toolchain Update
Hi Alan, On Fri, Sep 25, 2015 at 01:33:34PM +0100, Nick Clifton wrote: * The new PowerPC64 specific linker command line option --no-save-restore-funcs tells the linker not to provide the out-of-line register save and restore functions used by -Os compiled code. The default is to provide any such referenced function for a normal final link, but not do so for a relocatable link. Actually, --save-restore-funcs and --no-save-restore-funcs have been around since 2014-02. The recent new PowerPC64 option is --tls-get-addr-optimize, a complement to --no-tls-get-addr-optimize. Doh! Sorry about that. Cheers Nick
Commit: MSP430: Add support for more MCUs
Hi Guys, I am applying the attached patch to add support for more MSP430 MCUs to the MSP430 target. The names and data have been copied directly from the the latest devices.csv file released by TI. The patch also updates the documentation on the MSP430's -mmcu option to note that if the MCU name is not recognised the compiler will assume that is only supports the MSP430 instruction set, and that it does not have any hardware multiply support. Tested with no regressions on an msp430-elf toolchain. Cheers Nick gcc/ChangeLog 2015-10-12 Nick Clifton * config/msp430/msp430.c (msp430_mcu_names): Rename to msp430_mcu_data, add fields for ISA and hardware multiply support. Import latest data from the devices.csv file. (msp430_override_option): Use the data from the new array. (msp430_use_f5_series_hwmult): Likewise. (use_32bit_hwmult): Likewise. (msp430_no_hwmult): Likewise. * config/msp430/t-msp430 (MULTILIB_MATCHES): Add matches for new MCU names. * doc/invoke.texi (MSP430 Options): Note that if the MCU name is not recognised then no hardware multiply support is assumed and that only the MSP430 ISA is allowed. fred Description: Binary data
October/November GNU Toolchain Update
Hi Guys,
Sorry for the delay between these updates. My new job is keeping
me very busy... Anyway here are the highlights of the changes in
the GNU toolchain over the last two months:
The compiler and assembler now have support for the ARC EM/HS and
ARC600/700 architectures and the Power9 variant of the PowerPC
architecture.
The GCC mainline sources are now in Stage 3 (bug fixes only) which
means that a branch may be happening soon.
The Binutils sources have branched, getting ready for a 2.26 release
soon.
GDB's record instruction-history command accepts a new modifier: /s.
This behaves exactly like the /m modifier and prints mixed source +
disassembly into the history.
GDB now supports displaced stepping on AArch64 GNU/Linux.
GCC's named address space feature has been extended to add address
spaces for the x86 architecture. Here variables may be declared as
being relative to the %fs or %gs segments using the __seg_fs and
__seg_gs attributes. Alternatively if one of these segments is used
for thread local storage then the __seg_tls attribute can be used
access the correct segment.
GCC's function attribute feature has been extended to support
another attribute:
target_clones ()
This is used to specify that a function is to be cloned into
multiple versions compiled with different target options than
specified on the command line. The supported options and
restrictions are the same as for target attribute.
For instance on an x86, you could compile a function with
target_clones("sse4.1,avx"). It will create 2 function clones,
one compiled with -msse4.1 and another with -mavx. At the function
call it will create resolver ifunc, that will dynamically call a
clone suitable for current architecture.
A new type attribute has been added to specify the endianness of the
fields in a struct, union or array:
scalar_storage_order ("")
This attribute sets the storage order, aka endianness, of the scalar
fields of the type to either "big-endian" or "little-endian". The
attribute has no effects on fields which are themselves a union, a
struct or an array whose component is a union or a struct, and it is
possible to have fields with a different scalar storage order than
the enclosing type.
Additional restrictions are enforced for types with the reverse
scalar storage order with regard to the scalar storage order of the
target:
* Taking the address of a scalar field of a union or a struct with
reverse scalar storage order is not permitted and will yield an
error.
* Taking the address of an array field, whose component is scalar,
of a union or a struct with reverse scalar storage order is
permitted but will yield a warning, unless the option
-Wno-scalar-storage-order is specified.
* Taking the address of a union or a struct with reverse scalar
storage order is permitted.
These restrictions exist because the storage order attribute is lost
when the address of a scalar or the address of an array with scalar
component is taken, so storing indirectly through this address will
generally not work. The second case is nevertheless allowed to be
able to perform a block copy from or to the array.
A new warning option: -Wduplicated-cond will produce messages
whenever a condition is duplicated in an if-else-if chain. For
example:
if (p->q != NULL) { ... }
else if (p->q != NULL) { ... }
A new option: -fkeep-static-functions will make sure that gcc will
generate code for static functions that are never used.
The block reordering optimization in gcc can now be tuned via the
option: -freorder-blocks-algorithm=. The default for
optimization levels below -O2 (or at -Os) is the "simple" algorithm
which does not increase code size. The new "stc" algorithm stands
for "software trace cache" and it tries to put all often executed
code together, minimizing the number of branches executed by
making extra copies of code.
The ARM backend supports a new option: -mlow-precision-recip-sqrt
which uses two steps instead of three for double-precision
reciprocal square root calculations. (It also uses one step instead
of two steps for single-precision calculations). This reduces the
latency and precision of the operation.
The x86 and x86_64 backends support a new option: -mms-bitfields
This enables a bit-field layout compatible with the native Microsoft
Windows compiler. This option is enabled by default for Windows
targets.
The x86 and x86_64 backends also support the new option:
-mmitigate-rop
This tries to avoid generating code sequences that contain
unintended return opcodes, to mitigate against certain forms of
attack. At the moment, this option is limited in what it can do and
should not be relied on to provide serious protection.
The assembler and linker now supp
December/January (15/16) GNU Toolchain Update
's InferiorThread.num attribute are no longer unique between inferiors. GDB now maintains a second thread ID per thread, referred to as the global thread ID, which is the new equivalent of thread numbers in previous releases. See also $_gthread below. For backwards compatibility, MI's thread IDs always refer to global IDs. Commands that accept thread IDs now accept the qualified INF_NUM.THR_NUM form as well. For example: (gdb) thread 2.1 [Switching to thread 2.1 (Thread 0x77fc2740 (LWP 8157))] (running) (gdb) In commands that accept a list of thread IDs, you can now refer to all threads of an inferior using a star wildcard. GDB accepts "INF_NUM.*", to refer to all threads of inferior INF_NUM, and "*" to refer to all threads of the current inferior. For example, "info threads 2.*". You can use "info threads -gid" to display the global thread ID of all threads. The new convenience variable $_gthread holds the global number of the current thread, and $_inferior holds the number of the current inferior. * GDB now displays the ID and name of the thread that hit a breakpoint or received a signal, if your program is multi-threaded. For example: Thread 3 "bar" hit Breakpoint 1 at 0x40087a: file program.c, line 20. Thread 1 "main" received signal SIGINT, Interrupt. That's all for now. More again in a couple of month's time. Cheers Nick
February/March 2016 GNU Toolchain Update
eric values. This allows extra or unusual bits in these fields to be set. * GAS for x86 targets now also supports a command line option of "-mfence-as-lock-add=yes" which encodes the lfence, mfence and sfence opcodes as "lock addl $0x0, (%[re]sp)". * The ARC port of GAS now supports assembly-time relaxation. And last, bit not least, there is a new feature in newlib as well: * Newlib now supports the clog10 and clog10f math functions. That's it for this report. Back in two months time. Meanwhile I have a minor plug to offer: some other Red Hat developers have written blogs about new features that will be in the upcoming GCC 6 release. So if you are interested in what will happen, please see: http://developerblog.redhat.com/2016/02/23/upcoming-features-in-gcc-6/ and: http://developerblog.redhat.com/2016/02/26/gcc-6-wmisleading-indentation-vs-goto-fail/ Cheers Nick
April/May 2016 GNU Toolchain Update
Hi Guys,
Well now that GCC 6 is out lets see what new features have started
to appear in the toolchain:
Several new warning options have been added to GCC:
* The option -Wno-duplicate-decl-specifier has been added to
generate warnings whenever a declaration contains duplicate const,
volatile, restrict or _Atomic specifiers. This warning is enabled
by -Wall.
* The option -Wignored-attributes warns when an attribute is
correctly assigned, but the compiler decided to ignore it anyway.
This is different from the -Wattributes which warns when an
attribute is either unknown or used in the wrong place.
* The option -Wswitch-unreachable warns whenever a switch statement
contains statements between the controlling expression and the
first case label, which will never be executed. For example:
switch (cond)
{
i = 15;
case 5:
The option does not warn if the statement(s) between the
controlling expression and the first case label are just variable
declarations:
switch (cond)
{
int i;
case 5:
* The option -Wdangling-else warns about constructions where there
may be confusion to which if statement an else branch belongs.
For example:
if (a)
if (b)
foo ();
else
bar ();
* The option -Wmemset-elt-size warns about suspicious calls to
the memset function, if the first argument references an array,
and the third argument is a number equal to the number of
elements, but not equal to the size of the array in memory.
For example:
int array[10];
memset (array, 0, 10); // Should be: memset (array, 0, 10 * sizeof
(int));
A new point release of GDB is out: 7.11.1. This is a bugfix release
addressing these issues:
* PR remote/19863 (7.10 regression: gdb remote.c due to "setfs" with
gdbserver < 7.7)
* PR gdb/19829 (gdb crashes with PT and reverse next)
* PR gdb/19676 (gdb fails with assert error if /proc is not mounted)
* PR gdb/19828 (7.11 regression: non-stop gdb -p : internal error)
* PR remote/19840 (gdb crashes on reverse-stepi)
* PR gdb/19858 (GDB doesn't register the JIT libraries on attach)
* PR gdb/19958 (Breakpoints/watchpoints broken on MIPS Linux <= 4.5)
* PR build/20029 (symfile.c ambiguous else warning)
* PR python/20037 (GDB use-after-free error)
* PR gdb/20039 (Using MI/all-stop, can't interrupt multi-threaded
program after continue)a
In the development GDB sources a couple of new features have been
added:
* Fortran: Support structures with fields of dynamic types and
arrays of dynamic types.
* Rust language support.
GDB now supports debugging programs written in the Rust
programming language.
Development in the binutils has mostly concentrated on bugfixing,
but there have been a few new features added:
* The ARM port of GAS now has support for the ARMv8-M architecture,
including the security and DSP extensions.
* The ARC port of GAS now accepts .extInstruction, .extCondCode,
.extAuxRegister, and .extCoreRegister pseudo-ops that allow an
user to define custom instructions, conditional codes, auxiliary
and core registers.
* The MIPS port of GAS can now generate code for the DSP Release 3
Application Specific Extension.
* Linker scripts can now use a NOCROSSREFSTO directive. This is
like the NOCROSSREFS directive which ensures that two or more
output sections are entirely independent from each other, except
that it does allow one way referencing. The NOCROSSREFS_TO
directive takes a list of output section names and complains if
the first section is referenced from any of the other sections.
Cheers
Nick
August 2016 GNU Toolchain Update
ow supports the use of built-in functions that allow direct access to the Hardware Transactional Memory (HTM) instructions that were added in version 2.07 of the PowerPC ISA. The linker has extended the --out-implib= option, previously restricted to x86 PE targets, to any ELF based target. This allows the generation of an import library for an ELF executable, which can then be used by another application to link against the executable. This feature is now used by the ARM port of the linker to create import libraries suitable for use in the generation of Secure Gateways, as per the ARMv8-M Security Extensions. The objdump program now supports the use of the -M option with ARC targets to specify the instruction class(es) that should be disassembled. The objcopy and strip programs now accept section patterns starting with an exclamation point to indicate any section not matching the pattern. In addition a new option --remove-relocations= can be used to remove sections containing relocations. GDB has added support for thread names on MS-Windows. In addition it can now catch and handle the special exception that programs running on MS-Windows use to assign names to threads in the debugger. In Newlib the entire set of locale-specific functions from POSIX-1.2008 has now been implemented with one exception: strfmon_l. This means that any character handling function (eg isalnum, toascii, etc) and any string handling function (eg strtoll) now has a locale based equivalent (isalnum_l, toascii_l, strtoll_l, etc). Cheers Nick
Re: [PATCH MIPS] Work around Bash 4.2 bug
Hi Maciej, >>> The patch below works around the Bash 4.2 bug described at >>> <http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-007>. >> >>> * emulparams/elf32bmipn32-defs.sh: Shift quote of >>> "x$EMULATION_NAME" to the left to work around >>> <http://ftp.gnu.org/gnu/bash/bash-4.2-patches/bash42-007>. >>> >> >>> >>> -case x"$EMULATION_NAME" in >>> +case "x$EMULATION_NAME" in >>> xelf32*n32*) ELFSIZE=32 ;; >> >> Random comment from the sideline: pretty please add a comment >> regarding the bug workaround *on top of the actual changed code* >> (remember: the "why" goes in the code, not in the changelog), so >> it has a better chance of not being inadvertently reverted but >> instead propagating elsewhere. > > CC-ing as this might affect them too. > > Hmm, the shell construct is so common that I think rather than auditing > all the scripts throughout our tree I'd rather made a `configure' check > for the buggy shell feature and reject any shell affected at the top level > and across subdirectories. This way we won't have to keep an eye too for > future script changes which might reintroduce the construct elsewhere. > > Nick, WDYT? Hmm - well it has been 5 years since bug was fixed, but if we are receiving error reports connected to it today then buggy versions must still be in use. A quick grep shows that there are quite a few places in the gcc and binutils configure scripts that use the problematic form, so I agree that fixing them all, and stopping the problem from recurring in the future, would be hard to do. All in all, I think that your idea is the best way forwards, so yes, I would support it. Cheers Nick
November 2016 GNU Toolchain Update
calize, canonicalizef, canonicalizel. . NaN functions: getpayload, getpayloadf, getpayloadl. - New libc functions: strfromd, strfromf, and strfroml. * The header now includes the header. Support for the Linux quota interface which pre-dates kernel version 2.4.22 has been removed. * The malloc_get_state and malloc_set_state functions have been removed. Already-existing binaries that dynamically link to these functions will get a hidden implementation in which malloc_get_state is a stub. * The “ip6-dotint” and “no-ip6-dotint” resolver options, and the corresponding RES_NOIP6DOTINT flag from have been removed. “no-ip6-dotint” had already been the default, and support for the “ip6-dotint” option was removed from the Internet in 2006. * The "ip6-bytestring" resolver option and the corresponding RES_NOIP6DOTINT flag from have been removed. * DNSSEC-related declarations and definitions have been removed from the header file, and libresolv will no longer attempt to decode the data part of DNSSEC record types. * The resource record type classification macros ns_t_qt_p, ns_t_mrr_p, ns_t_rr_p, ns_t_udp_p, ns_t_xfr_p have been removed from the header file because the distinction between RR types and meta-RR types is not officially standardized, subject to revision, and thus not suitable for encoding in a macro. * The types res_sendhookact, res_send_qhook, re_send_rhook, and the qhook and rhook members of the res_state type in have been removed. GDB 7.12 is now out (really this time). In addition the development sources has a nice new feature for MS-Windows developers: * Native debugging on MS-Windows supports command-line redirection Command-line arguments used for starting programs on MS-Windows can now include redirection symbols supported by native Windows shells, such as '<', '>', '>>', '2>&1', etc. This affects GDB commands such as "run", "start", and "set args", as well as the corresponding MI features. And lastly the binutils development sources have a couple of new tricks up its sleaves: * Support has been added for the RISC-V architecture. * The nm program has a new command lien option (--with-version-strings) which will display a symbol's version information, if any, after the symbol's name. * The EXCLUDE_FILE linker script construct can now be applied outside of the section list in order for the exclusions to apply over all input sections in the list. * The command line option --no-eh-frame-hdr can now be used in ELF based linkers to disable the automatic generation of .eh_frame_hdr sections. * The ARM linker now supports --in-implib= to enable specifying a set of Secure Gateway veneers that must exist in the output import library specified by --out-implib= and the address they must have. That's all for now. Hopefully the next update will be a bit sooner in arriving. Cheers Nick
April GNU Toolchain Update
Hi Guys, This is an experimental posting of an extended version of my gcc blog. Every month I post an update covering changes in gcc, the binutils, newlib, and gdb here: http://nickclifton.livejournal.com/ It was suggested that readers of this mailing list might be interested in the information too, so I am posting this trial run. If you hate it, please let me know and I will stop. If you like then please also let me know and I will continue. If you find mistakes or omissions, then I will not be surprised, but I will be very glad to hear them. The blog itself came about because every month I perform a merge between the public FSF sources and Red Hat's internal, development sources. During the course of this merge I often find out about changes and updates that I had not even realised had happened. I also try to keep track of how well different targets are building and performing in order to get an overall feel for the state of the sources. Cheers Nick --- There are several things to report this month: * The GCC version 5 branch has been created. No releases have been made from this branch yet, but when one happens it will be GCC 5.1. Meanwhile the mainline development sources have been switched to calling themselves GCC version 6. * Support has been added for configuring targets that use the Nuxi CloudABI. More details of this ABI can be found here: https://github.com/NuxiNL/cloudlibc * The linker and assembler now support an option to control how DWARF debug sections are compressed: --compress-debug-sections=[none|zlib|zlib-gnu|zlib-gabi] Selecting NONE disables compression. This is the default behaviour if this option is not used. Selecting ZLIB or ZLIB-GNU compresses the sections and then renames them to start with a .z. This is the old method of indicating that a debug section has been compressed. Selecting ZLIB-GABI compresses the sections, but rather than renaming them they instead have the new SHF_COMPRESSED bit set in their ELF section header. The other binutils tools have been updated to recognise and handle this SHF_COMPRESSED bit. More information on the new bit can be found here: https://groups.google.com/forum/#!msg/generic-abi/dBOS1H47Q64/PaJvELtaJrsJ In another, related change, the binutils will no longer compress a debug section if doing so would actually make it bigger. Also the zlib compression/decompression library sources have now been brought in to the binutils git repository and are now a standard part of a binutils release. * The linker has a new command line option: --warn-orphan This option tells the linker to generate a warning message whenever it has to guess at the placement of a section in the output file. This happens when the linker script in use does not specify where the section should go. * The compiler has a new option: -fsanitize-sections=sec1,sec2,... This tells the address sanitizer to add protection to global variables defined in the named section(s). By default any globals in sections with user defined names are not sanitized as the compiler does not know what is going to happen to them. In particular variables in such sections sometimes end up being merged into an array of values, where the presence of address sanitization markers would break the array. * The AVR port of the compiler has a new command line option: -nodevicelib This tells the compiler not to link against AVR-LibC's device specific library libdev.a. * The RX port of GCC has a new command line option to disable the use of RX string instructions (SMOVF, SUNTIL, etc). This matters because it is unsafe to use these instructions if the program might access the I/O portion of the address space. * The RL78 port of GCC now has support the multiply and divide instructions provided by the G14 cpu, and the divide hardware peripheral provided by the G13 core. * GDB now honours the content of the file /proc/PID/coredump_filter (PID is the process ID) on GNU/Linux systems. This file can be used to specify the types of memory mappings that will be included in a corefile. For more information, please refer to the manual page of "core(5)". GDB also has a new command: "set use-coredump-filter on|off". It allows to set whether GDB will read the content of the /proc/PID/coredump_filter file when generating a corefile. * GDB's "info os cpus" command on GNU/Linux can now display information on the cpus/cores on the system. * GDB has two new commands: "set serial parity odd|even|none" and "show serial parity".
May 2015 Toolchain Update
Hi Guys,
There are several things to report this month:
* GCC now supports targets configured to use the MUSL C library:
http://www.musl-libc.org/
* The Compiler has a new warning option: -Wmisleading-indentation
This generates warnings when the indentation of the code does
not reflect the block structure. For example:
if (some_condition ())
foo ();
bar (); /* Gotcha: this is not guarded by the "if". */
The warning is disabled by default.
* The Compiler also has a new shift warning: -Wshift-negative-value
This generates warnings when left shifting a negative value.
The warning is enabled by -Wextra in C99 and C++11 modes (and
newer). The warning can be suppressed by an appropriate cast.
For example:
val |= ~0 << loaded;// Generates warning
val |= (unsigned) ~0 << loaded; // Does not warn
* GCC supports a new option: -fno-plt
When compiling position independent code this tells the compiler
not to use PLT for external function calls. Instead the address
is loaded from the GOT and then branched to directly. This
leads to more efficient code by eliminating PLT stubs and
exposing GOT load to optimizations.
Not all architectures support this option, and some other
optimization features, such as lazy binding, may disable it.
* GCC's sanitizer has a new option: -fsanitize=bounds-strict
This option enables strict instrumentation of array bounds.
Most out of bounds accesses are detected, including flexible
array members and flexible array member-like arrays.
* The AArch64 backend supports a new option to enable a workaround
for the ARM Cortex-A53 erratum number 843419. The workaround
itself is implemented in the linker, but it can be enabled via
the compiler option:
-mfix-cortex-a53-843419
Note, specifying -mcpu=cortex-a53 is not enough to enable this
option as not all versions of the A53 need the erratum.
* The AArch64 backend also supports a new core type of "native".
When used as -mcpu=native or -mtune=native it tells the backend
to base its core selection on the host system. If the compiler
cannot recognise the processor of the host system then the
option does nothing.
* The Linker now supports the Intel MCU architecture:
https://groups.google.com/forum/#!topic/ia32-abi/cn7TM6J_TIg
* GDB 7.9.1 has been released!
GDB 7.9.1 brings the following fixes and enhancements over GDB 7.9:
+ PR build/18033 (C++ style comment used in gdb/iq2000-tdep.c and
gdb/compile/compile-*.c)
+ PR build/18298 ("compile" command cannot find compiler if tools
configured with triplet instead of quadruplet)
+ PR tui/18311 (Random SEGV when displaying registers in TUI mode)
+ PR python/18299 (exception when registering a global
pretty-printer in verbose mode)
+ PR python/18066 (argument "word" seems broken in Command.complete
(text, word))
+ PR pascal/17815 (Fix pascal behavior for class fields with testcase)
+ PR python/18285 (ptype expr-with-xmethod causes SEGV)
Cheers
Nick
GCC Merge:
Toolchains that do not build GCC successfully:
None.
Toolchains that do not build LIBGCC successfully:
mep-elf: ICE: in pre_and_rev_post_order_compute, at cfganal.c
Toolchains that do not build NEWLIB successfully:
None.
Toolchains that do not build the target LIBIBERTY successfully:
None.
Toolchains that do not build LIBSTDC++-V3 successfully:
cr16-elf:ICE: in gen_rtx_SUBREG in emit-rtl.c
m32c-elf:ICE: in connect_traces, at dwarf2cfi.c
Toolchains that fail to build GDB:
Not supported:
arc-elf cr16-elfepiphany-elf
ia64-elfmcore-elf mmix-mmixware
nds32le-elf nios2-elf pdp11-aout
tilepro-gnu-linux visium-elf
No sim:
mips64vr-elf
Toolchains that DO build all their target libraries and gdb:
aarch64-elf arm-eabiavr-elf
bfin-elfc6x-elf cris-elf
frv-elf h8300-elf i386-elf
iq2000-elf lm32-elfm32r-elf
mipsisa32-elf mipsisa64-elf mn10300-elf
moxie-elf msp430-elf rl78-elf
powerpc-eabispe powerpc-elf rx-elf
sh-elf sh64-elfspu-elf
tx39-elfv850e-elf visium-elf
xstormy16-elf
[SIM based] GCC DG Testsuite Results
The chart below is sorted on the number of unexpected
failures, rather than alphabetically, in order to provide a
small guide to too
