Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions
On 03/02/2020 18:09, Michael Matz wrote: But suggesting that using the subject line for tagging is recommended can lead to subjects like [PATCH][GCC][Foo][component] Fix foo component bootstrap failure in an e-mail directed to gcc-patc...@gcc.gnu.org (from somewhen last year, where Foo/foo was an architecture; I'm really not trying to single out the author). That is, _none_ of the four tags carried any informational content. I partially disagree with this. Certainly there's pointless redundancy it this example, but I'd rather have the tags with a meaningful subject than a generic subject with no tags. gcc-patches is a high-volume list in which most of the content is outside my range of interest and/or understanding. If I stay on top of it then I can read all the subject lines, at least, and probably select a few threads to learn about something new, but if I let the list get away from me for even a short while then it's too much to handle. I do have filters set up to highlight subjects for which I should pay attention and if people are in the habit of tagging subjects then that becomes much more reliable. Conversely, the tags help me quickly decide what not to read. I see that some people are using a "[email tag] git tag: msg" format, and I quite like that. Andrew
GCC build error on FreeBSD 12.1 with LLVM 8.0.1
Hello,
I tried to build a recent GCC master on FreeBSD 12.1 and it failed with
a compile error:
$ clang --version
FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based on
LLVM 8.0.1)
Target: x86_64-unknown-freebsd12.1
Thread model: posix
InstalledDir: /usr/bin
../../gnu-mirror-gcc-5bc9d2f5ed4/gcc/analyzer/engine.cc:2965:13: error:
reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
v.m_fun = reinterpret_cast (NULL);
^~~
../../gnu-mirror-gcc-5bc9d2f5ed4/gcc/analyzer/engine.cc:2977:21: error:
reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
return v.m_fun == reinterpret_cast (NULL);
^~~
This simple test program fails also:
struct function;
function *f(void)
{
return reinterpret_cast(nullptr);
}
$ clang -c test.cc
test.cc:5:10: error: reinterpret_cast from 'nullptr_t' to 'function *'
is not allowed
return reinterpret_cast(nullptr);
^
1 error generated.
I was able to build the GCC master on January 2nd 2020. Does this look
like an LLVM 8.0.1 issue or a GCC issue?
Re: GCC build error on FreeBSD 12.1 with LLVM 8.0.1
On Tue, Feb 04, 2020 at 02:53:42PM +0100, Sebastian Huber wrote: > I tried to build a recent GCC master on FreeBSD 12.1 and it failed with a > compile error: That is http://gcc.gnu.org/PR93543 Jakub
[PATCH] analyzer: fix build error with clang (PR 93543)
On Tue, 2020-02-04 at 14:53 +0100, Sebastian Huber wrote:
> Hello,
>
> I tried to build a recent GCC master on FreeBSD 12.1 and it failed
> with
> a compile error:
>
> $ clang --version
> FreeBSD clang version 8.0.1 (tags/RELEASE_801/final 366581) (based
> on
> LLVM 8.0.1)
> Target: x86_64-unknown-freebsd12.1
> Thread model: posix
> InstalledDir: /usr/bin
>
> ../../gnu-mirror-gcc-5bc9d2f5ed4/gcc/analyzer/engine.cc:2965:13:
> error:
> reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
>v.m_fun = reinterpret_cast (NULL);
> ^~~
> ../../gnu-mirror-gcc-5bc9d2f5ed4/gcc/analyzer/engine.cc:2977:21:
> error:
> reinterpret_cast from 'nullptr_t' to 'function *' is not allowed
>return v.m_fun == reinterpret_cast (NULL);
> ^~~
>
> This simple test program fails also:
>
> struct function;
>
> function *f(void)
> {
>return reinterpret_cast(nullptr);
> }
>
> $ clang -c test.cc
> test.cc:5:10: error: reinterpret_cast from 'nullptr_t' to 'function
> *'
> is not allowed
>return reinterpret_cast(nullptr);
> ^
> 1 error generated.
>
> I was able to build the GCC master on January 2nd 2020. Does this
> look
> like an LLVM 8.0.1 issue or a GCC issue?
Sorry, this was my code.
This is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93543
Does this patch fix the build for you with clang?
gcc/analyzer/ChangeLog:
PR analyzer/93543
* engine.cc (pod_hash_traits::mark_empty):
Eliminate reinterpret_cast.
(pod_hash_traits::is_empty): Likewise.
---
gcc/analyzer/engine.cc | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 90f7067dec1..81b8a76c5eb 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -2962,7 +2962,7 @@ template <>
inline void
pod_hash_traits::mark_empty (value_type &v)
{
- v.m_fun = reinterpret_cast (NULL);
+ v.m_fun = NULL;
}
template <>
inline bool
@@ -2974,7 +2974,7 @@ template <>
inline bool
pod_hash_traits::is_empty (value_type v)
{
- return v.m_fun == reinterpret_cast (NULL);
+ return v.m_fun == NULL;
}
namespace ana {
--
2.21.0
Re: [PATCH] analyzer: fix build error with clang (PR 93543)
On Tue, Feb 04, 2020 at 09:00:37AM -0500, David Malcolm wrote:
> gcc/analyzer/ChangeLog:
> PR analyzer/93543
> * engine.cc (pod_hash_traits::mark_empty):
> Eliminate reinterpret_cast.
> (pod_hash_traits::is_empty): Likewise.
This is ok for trunk.
> gcc/analyzer/engine.cc | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
> index 90f7067dec1..81b8a76c5eb 100644
> --- a/gcc/analyzer/engine.cc
> +++ b/gcc/analyzer/engine.cc
> @@ -2962,7 +2962,7 @@ template <>
> inline void
> pod_hash_traits::mark_empty (value_type &v)
> {
> - v.m_fun = reinterpret_cast (NULL);
> + v.m_fun = NULL;
> }
> template <>
> inline bool
> @@ -2974,7 +2974,7 @@ template <>
> inline bool
> pod_hash_traits::is_empty (value_type v)
> {
> - return v.m_fun == reinterpret_cast (NULL);
> + return v.m_fun == NULL;
> }
>
> namespace ana {
> --
> 2.21.0
Jakub
Re: [PATCH] analyzer: fix build error with clang (PR 93543)
On Tue, 2020-02-04 at 16:26 +0100, Jakub Jelinek wrote: > On Tue, Feb 04, 2020 at 09:00:37AM -0500, David Malcolm wrote: > > gcc/analyzer/ChangeLog: > > PR analyzer/93543 > > * engine.cc > > (pod_hash_traits::mark_empty): > > Eliminate reinterpret_cast. > > (pod_hash_traits::is_empty): Likewise. > > This is ok for trunk. Thanks. This should now be fixed on master (r10-6434- g1dae549dccfec1edb0cb4e65feadc4722bb3bcc8); I verified the build with the patch with gcc, and Sebastian verified it with clang. Sorry about the breakage Dave
Re: [PATCH] analyzer: fix build error with clang (PR 93543)
On 04/02/2020 16:45, David Malcolm wrote: On Tue, 2020-02-04 at 16:26 +0100, Jakub Jelinek wrote: On Tue, Feb 04, 2020 at 09:00:37AM -0500, David Malcolm wrote: gcc/analyzer/ChangeLog: PR analyzer/93543 * engine.cc (pod_hash_traits::mark_empty): Eliminate reinterpret_cast. (pod_hash_traits::is_empty): Likewise. This is ok for trunk. Thanks. This should now be fixed on master (r10-6434- g1dae549dccfec1edb0cb4e65feadc4722bb3bcc8); I verified the build with the patch with gcc, and Sebastian verified it with clang. Thanks a lot for the quick fix. The master builds now again.
Fwd: February sourceware.org transition to new server!
This affects gcc.gnu.org as well...Expect weekend outages... --- Begin Message --- Community, The sourceware.org server will be transitioning to a new server over the next 2-4 weeks. The new server will be CentOS 8-based with more CPU and more RAM. Please keep this in mind when planning out your work. Starting in 2 weeks time we might see some weekend outages as Frank Eigler and the overseers team work out the bugs. Thanks to Frank and all of overseers for their tireless efforts! Cheers, Carlos. --- End Message ---
Git question: Rebasing a user branch
I'm having a little difficulty with my workflow, and I'm hoping someone can spot the problem. I have a user branch set up with the contrib/git-add-user-branch.sh script. Here are the relevant portions of my .git/config: [remote "users/wschmidt"] url = git+ssh://wschm...@gcc.gnu.org/git/gcc.git fetch = +refs/users/wschmidt/heads/*:refs/remotes/users/wschmidt/* fetch = +refs/users/wschmidt/tags/*:refs/tags/users/wschmidt/* push = refs/heads/wschmidt/*:refs/users/wschmidt/heads/* [branch "wschmidt/builtins"] remote = users/wschmidt merge = refs/users/wschmidt/heads/builtins I originally created the branch from master. I then made 15 local commits, and pushed these upstream. I now want to rebase my branch from master, and reflect this state upstream. My recipe is: git checkout master git pull git checkout wschmidt/builtins git rebase master git push --dry-run users/wschmidt +wschmidt/builtins After the rebase step, git status shows: On branch wschmidt/builtins Your branch and 'users/wschmidt/builtins' have diverged, and have 39 and 15 different commits each, respectively. (use "git pull" to merge the remote branch into yours) nothing to commit, working tree clean Looks fine to me, so lets try the force push: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git * [new branch] wschmidt/builtins -> wschmidt/builtins Well, that's odd, why is it trying to create a new branch? If I inadvisedly attempt to push without --dry-run, I am stopped from creating the new branch: remote: *** Shared development branches should be named devel/*, and should be documented in https://gcc.gnu.org/git.html . remote: error: hook declined to update refs/heads/wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] wschmidt/builtins -> wschmidt/builtins (hook declined) error: failed to push some refs to 'git+ssh://wschm...@gcc.gnu.org/git/gcc.git' It seems wrong that it is trying to update refs/head/wschmidt/builtins (thus creating a new branch). It seems like there may be a missing "users/" needed someplace. But I am not at all confident that's correct. I'm a little suspicious of the push spec in my config. Can someone with strong git-fu give me any suggestions? Best regards, Bill
Re: Git question: Rebasing a user branch
On Tue, Feb 4, 2020 at 2:03 PM Bill Schmidt wrote: > > I'm having a little difficulty with my workflow, and I'm hoping someone > can spot the problem. > > I have a user branch set up with the contrib/git-add-user-branch.sh > script. Here are the relevant portions of my .git/config: > > [remote "users/wschmidt"] > url = git+ssh://wschm...@gcc.gnu.org/git/gcc.git > fetch = +refs/users/wschmidt/heads/*:refs/remotes/users/wschmidt/* > fetch = +refs/users/wschmidt/tags/*:refs/tags/users/wschmidt/* > push = refs/heads/wschmidt/*:refs/users/wschmidt/heads/* > [branch "wschmidt/builtins"] > remote = users/wschmidt > merge = refs/users/wschmidt/heads/builtins > > I originally created the branch from master. I then made 15 local > commits, and pushed these upstream. > > I now want to rebase my branch from master, and reflect this state > upstream. My recipe is: > > git checkout master > git pull > git checkout wschmidt/builtins > git rebase master > git push --dry-run users/wschmidt +wschmidt/builtins > > After the rebase step, git status shows: > > On branch wschmidt/builtins > Your branch and 'users/wschmidt/builtins' have diverged, > and have 39 and 15 different commits each, respectively. >(use "git pull" to merge the remote branch into yours) > > nothing to commit, working tree clean > > Looks fine to me, so lets try the force push: > > wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run > users/wschmidt +wschmidt/builtins > To git+ssh://gcc.gnu.org/git/gcc.git > * [new branch] wschmidt/builtins -> wschmidt/builtins > > Well, that's odd, why is it trying to create a new branch? > > If I inadvisedly attempt to push without --dry-run, I am stopped from > creating the new branch: > > remote: *** Shared development branches should be named devel/*, and > should be documented in https://gcc.gnu.org/git.html . > remote: error: hook declined to update refs/heads/wschmidt/builtins > To git+ssh://gcc.gnu.org/git/gcc.git > ! [remote rejected] wschmidt/builtins -> wschmidt/builtins You can use "git push -f" or $ git push origin :yourbranch $ git push -u origin yourbranch Since it is hassle to use 2 commands, I use gitlab.com for my own work. > (hook declined) > error: failed to push some refs to > 'git+ssh://wschm...@gcc.gnu.org/git/gcc.git' > > It seems wrong that it is trying to update refs/head/wschmidt/builtins > (thus creating a new branch). It seems like there may be a missing > "users/" needed someplace. But I am not at all confident that's > correct. I'm a little suspicious of the push spec in my config. > > Can someone with strong git-fu give me any suggestions? > > Best regards, > Bill > -- H.J.
Re: Git question: Rebasing a user branch
On 2/4/20 5:02 PM, Bill Schmidt wrote: I'm having a little difficulty with my workflow, and I'm hoping someone can spot the problem. I have a user branch set up with the contrib/git-add-user-branch.sh script. Here are the relevant portions of my .git/config: [remote "users/wschmidt"] url = git+ssh://wschm...@gcc.gnu.org/git/gcc.git fetch = +refs/users/wschmidt/heads/*:refs/remotes/users/wschmidt/* fetch = +refs/users/wschmidt/tags/*:refs/tags/users/wschmidt/* push = refs/heads/wschmidt/*:refs/users/wschmidt/heads/* [branch "wschmidt/builtins"] remote = users/wschmidt merge = refs/users/wschmidt/heads/builtins Not sure why but this seems fishy to me. Does merge need to be the same as push if your trying to avoid creating a new branch. So removing the builtins and making it refs/users/wschmidt/heads/* would be my guess. I'm not a git expert through. Nick I originally created the branch from master. I then made 15 local commits, and pushed these upstream. I now want to rebase my branch from master, and reflect this state upstream. My recipe is: git checkout master git pull git checkout wschmidt/builtins git rebase master git push --dry-run users/wschmidt +wschmidt/builtins After the rebase step, git status shows: On branch wschmidt/builtins Your branch and 'users/wschmidt/builtins' have diverged, and have 39 and 15 different commits each, respectively. (use "git pull" to merge the remote branch into yours) nothing to commit, working tree clean Looks fine to me, so lets try the force push: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git * [new branch] wschmidt/builtins -> wschmidt/builtins Well, that's odd, why is it trying to create a new branch? If I inadvisedly attempt to push without --dry-run, I am stopped from creating the new branch: remote: *** Shared development branches should be named devel/*, and should be documented in https://gcc.gnu.org/git.html . remote: error: hook declined to update refs/heads/wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git ! [remote rejected] wschmidt/builtins -> wschmidt/builtins (hook declined) error: failed to push some refs to 'git+ssh://wschm...@gcc.gnu.org/git/gcc.git' It seems wrong that it is trying to update refs/head/wschmidt/builtins (thus creating a new branch). It seems like there may be a missing "users/" needed someplace. But I am not at all confident that's correct. I'm a little suspicious of the push spec in my config. Can someone with strong git-fu give me any suggestions? Best regards, Bill
Re: Git question: Rebasing a user branch
On Feb 04 2020, Bill Schmidt wrote: > wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run > users/wschmidt +wschmidt/builtins > To git+ssh://gcc.gnu.org/git/gcc.git > * [new branch] wschmidt/builtins -> wschmidt/builtins > > Well, that's odd, why is it trying to create a new branch? You told it so, with the refspec you used. Instead you want to push to users/wschmidt/builtins on the remote side, ie. +wschmidt/builtins:users/wschmidt/builtins. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Git question: Rebasing a user branch
On 2/4/20 4:31 PM, Andreas Schwab wrote: On Feb 04 2020, Bill Schmidt wrote: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git * [new branch] wschmidt/builtins -> wschmidt/builtins Well, that's odd, why is it trying to create a new branch? You told it so, with the refspec you used. Instead you want to push to users/wschmidt/builtins on the remote side, ie. +wschmidt/builtins:users/wschmidt/builtins. Hm. If I'm understanding you correctly, this still attempts to create a new branch: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins:users/wschmidt/builtins To git+ssh://gcc.gnu.org/git/gcc.git * [new branch] wschmidt/builtins -> users/wschmidt/builtins I expect I've misunderstood, though. Thanks! Bill Andreas.
Re: Git question: Rebasing a user branch
On Feb 04 2020, Bill Schmidt wrote: > Hm. If I'm understanding you correctly, this still attempts to create a > new branch: > > wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run > users/wschmidt +wschmidt/builtins:users/wschmidt/builtins Sorry, that needs to be fully qualified, as it is not under refs/heads (and /heads/ was missing on the remote side): +wschmidt/builtins:refs/users/wschmidt/heads/builtins Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Git question: Rebasing a user branch
On Feb 04 2020, Bill Schmidt wrote: > Looks fine to me, so lets try the force push: > > wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run > users/wschmidt +wschmidt/builtins It looks like the leading + on the refspec suppresses matching against the default push refspec. I think that's a bug in git. If you use the -f option and remove + from the refspec, it should work as expected. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: Git question: Rebasing a user branch
On 2/4/20 5:09 PM, Andreas Schwab wrote: On Feb 04 2020, Bill Schmidt wrote: Hm. If I'm understanding you correctly, this still attempts to create a new branch: wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run users/wschmidt +wschmidt/builtins:users/wschmidt/builtins Sorry, that needs to be fully qualified, as it is not under refs/heads (and /heads/ was missing on the remote side): +wschmidt/builtins:refs/users/wschmidt/heads/builtins Thanks! That worked: git push users/wschmidt +wschmidt/builtins:refs/users/wschmidt/heads/builtins Regarding your other suggestion, I don't like to use -f given that I've noticed it will sometimes attempt to push other local branches as well. But it looks to be unnecessary with this method. Much obliged! Bill Andreas.
Re: Git question: Rebasing a user branch
On 04/02/2020 23:26, Bill Schmidt wrote: > On 2/4/20 5:09 PM, Andreas Schwab wrote: >> On Feb 04 2020, Bill Schmidt wrote: >> >>> Hm. If I'm understanding you correctly, this still attempts to create a >>> new branch: >>> >>> wschmidt@marlin:~/newgcc/gcc/config/rs6000$ git push --dry-run >>> users/wschmidt +wschmidt/builtins:users/wschmidt/builtins >> Sorry, that needs to be fully qualified, as it is not under refs/heads >> (and /heads/ was missing on the remote side): >> >> +wschmidt/builtins:refs/users/wschmidt/heads/builtins > > > Thanks! That worked: > > git push users/wschmidt > +wschmidt/builtins:refs/users/wschmidt/heads/builtins > > Regarding your other suggestion, I don't like to use -f given that I've > noticed it will sometimes attempt to push other local branches as well. > But it looks to be unnecessary with this method. > git push -f users/wschmidt wschmidt/builtins shouldn't push anything other than wschmidt/builtins. Anything more really would be a bug as you've specified what you want to push explicitly. R. > Much obliged! > Bill > >> >> Andreas. >>
GSoC Questions
Greetings Martin, I won't be applied but it was good to see you at least got some possible ideas out of my research from the make parts. Two questions as related to GSoC, in terms of long term planning for my work: 1. *Implement something similar to Clang's/-ftime-trace/*is in my view the most important project for GCC multi-threading as having a real profiler in gcc proper is the biggest bottleneck. Finding shared state and having heuristics is a real thorn without it. Is the goal just to support it as a feature similar to Clang or is this intended to be a real profiler, as it seems so? 2.*Create a general jobserver client/server library *If its planning to be a library then your probably hooking it into the frontends for C/C++. Not sure who the maintainer for that is but is he aware of the possible changes? It may be good to either have him as another mentor or someone to ask about the frontend parts unless you or Martin Liska have that knowledge. Regards and good luck with GSoC, Nick**
