Re: TYPE_BINFO and canonical types at LTO
On 02/13/2014 04:48 PM, Jan Hubicka wrote: all bases are also fields of within the type, so the second loop should notice all the types seen by first loop if I am correct? Yes, except that empty bases don't get fields because they have no data. But since they have no data they aren't interesting to aliasing either, so you should be OK just looking at field types. Jason
Re: TYPE_BINFO and canonical types at LTO
On 02/15/2014 05:09 AM, Richard Biener wrote: On Sat, 15 Feb 2014, Jan Hubicka wrote: The code really seems to be adding only cases of zero sized classes. zero-size as in with no fields? Then we can't do anything with such classes and thus we don't need to record component aliases? Right. The TYPE_SIZE of an empty class is still 1, but a base of such a type doesn't get a FIELD_DECL. Jason
Re: TYPE_BINFO and canonical types at LTO
On 02/17/2014 03:55 PM, Jan Hubicka wrote: I also think we want explicit representation of types known to be local to compilation unit - anonymous namespaces in C/C++, types defined within function bodies in C and god knows what in Ada/Fortran/Java. In the C++ front end we set TREE_PUBLIC appropriately on the TYPE_DECL of a named type. Jason
Re: PowerPC IEEE 128-bit floating point: Language standards
On 06/02/2014 11:45 AM, Michael Meissner wrote: I have not been following the language standards recently. For any of the recent language standards, or the standards that are being worked on, will there be requirements for an IEEE 128-bit binary floating point type? For the C/C++ languages, is this type long double, or is another type being proprosed (such as __float128)? C++ doesn't require any particular value representation for arithmetic types. But std::numeric_limits::is_iec559 will let you know whether it conforms or not. Jason
Re: GCC version bikeshedding
On 07/20/2014 06:01 PM, Jakub Jelinek wrote: On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote: I understood we agreed on 5.0 and further 5.1, 5.2 releases from the branch and 6.0 a year later. With unspecified uses for the patch level number (so leave it at zero). Ian/Jason, is that your understanding too? I didn't think that we had come to a decision, but I don't mind going ahead with this pattern. Jason
Re: Issue with sub-object __builtin_object_size
On 09/15/2014 11:21 AM, Ulrich Weigand wrote:
Jakub Jelinek wrote:
On Tue, Jun 10, 2014 at 07:37:50PM +0200, Ulrich Weigand wrote:
the following C++ test case:
struct pollfd
{
int fd;
short int events;
short int revents;
};
struct Pollfd : public pollfd { };
struct Pollfd myfd[10];
int test (void)
{
return __builtin_object_size ((struct pollfd *)myfd, 1);
}
ends up returning 8 from the "test" routine, not 80.
This example strikes me as strange. Why do you expect the size of a
pointer to the base class subobject to give a meaningful answer, any
more than taking the address of a data member?
Jason
Re: Issue with sub-object __builtin_object_size
On 09/15/2014 11:55 AM, Ulrich Weigand wrote: (https://gcc.gnu.org/ml/gcc/2014-06/msg00116.html) From the __builtin_object_size documentation, it's not immediately clear to me whether this is supposed to work or not: If the least significant bit is clear, objects are whole variables, if it is set, a closest surrounding subobject is considered the object a pointer points to. Is the presence of the above cast (explicit or implicit) supposed to modify the notion of "closest surrounding subobject"? IMO, yes. A base class subobject is a subobject, so since the least significant bit is set, it seems to me that GCC is correctly returning the size of that subobject. Jason
Re: Issue with sub-object __builtin_object_size
On 09/16/2014 06:23 AM, Ulrich Weigand wrote:
I guess I'm still a bit confused about the special handling of the array
case. Even with the last bit set, array elements normally do not count
as "subobjects", so __builtin_object_size still returns the size of the
full array.
I expect that's because there isn't an easy way to distinguish between
the array and the first element.
Now in this case, we cast a pointer to the array to a pointer to a base
type of the array element type -- but the intent is for the pointer to still
refer to the whole array. (Of course, this only works if the base type
is actually the same size as the array type.)
And I'm arguing that this intent is not well expressed by the code. :)
If they want to refer to the whole array, why are they casting the
pointer to a different type? And why are they passing the "subobject
only" value as the second argument?
Note that with a somewhat equivalent C construct:
struct pollfd
{
int fd;
short int events;
short int revents;
};
struct Pollfd
{
struct pollfd x;
};
struct Pollfd myfd[10];
we still get an object size of 80 for either:
__builtin_object_size ((struct pollfd *)myfd, 1);
or even
__builtin_object_size (&myfd->x, 1);
That strikes me as a bug, especially the second one.
Jason
Re: Issue with sub-object __builtin_object_size
On 09/16/2014 08:27 AM, Jason Merrill wrote:
On 09/16/2014 06:23 AM, Ulrich Weigand wrote:
Note that with a somewhat equivalent C construct:
struct pollfd
{
int fd;
short int events;
short int revents;
};
struct Pollfd
{
struct pollfd x;
};
struct Pollfd myfd[10];
we still get an object size of 80 for either:
__builtin_object_size ((struct pollfd *)myfd, 1);
or even
__builtin_object_size (&myfd->x, 1);
That strikes me as a bug, especially the second one.
This seems to be happening because of the STRIP_USELESS_TYPE_CONVERSION
in gimplify_expr dropping the NOP_EXPR from the argument, otherwise the
NOP_EXPR would cause __builtin_object_size to give up. I don't think
this behavior is intentional...
I don't know why the C frontend is folding &myfd->x to (struct pollfd
*)myfd, though.
Is this "wrapping" of system types in a derived calls supposed to work?
If there is a better way to express this without breaking glibc headers,
I'd be happy to let the authors know ...
Well, __builtin_object_size seems to be pretty fragile magic. To make
it work I guess you could add a wrapper for poll that takes a Pollfd and
does a reinterpret_cast, i.e.
inline int poll(Pollfd* p, nfds_t n, int t)
{
return poll(reinterpret_cast(p), n, t);
}
so that you force the conversion to ignore the inheritance relationship
and thereby avoid the COMPONENT_REF.
Jason
Re: [PATCH] gcc parallel make check
On 09/12/2014 08:04 PM, Jakub Jelinek wrote:
I've been worried about the quick cases where
parallelization is not beneficial, like make check-gcc \
RUNTESTFLAGS=dg.exp=pr60123.c or similar, but one doesn't usually pass -jN
in that case.
I have -jN in my $MAKEFLAGS, so I've been running into this with my rgt
shell function:
rgt ()
{
( cd ~/m/$CANON/gcc/gcc;
make check-c++ ${1:+RUNTESTFLAGS="$*"} )
}
If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in
the explosion of shell verbosity. Could we add some '@'s to more of the
rules, perhaps?
Jason
Re: [PATCH] gcc parallel make check
On 09/22/2014 11:26 AM, Jakub Jelinek wrote:
On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote:
If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the
explosion of shell verbosity. Could we add some '@'s to more of the rules,
perhaps?
I've been considering that too, but not sure what info people find valuable
and what they don't.
I don't see much information in the ~128 repetitions of the
check-parallel rules with different numbers; the actual runtest command
is the same in all of them. Adding @ to all of the commands of the
check-parallel-% rule makes things much better for me:
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6f251a5..be4c840 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3674,10 +3674,10 @@ $(lang_checks_parallelized): check-% : site.exp
fi
check-parallel-% : site.exp
- -test -d plugin || mkdir plugin
- -test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
- test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir $(TESTSUITEDIR)/$(check_p_subdir)
- -(rootme=`${PWD_COMMAND}`; export rootme; \
+ -@test -d plugin || mkdir plugin
+ -@test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
+ @test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir $(TESTSUITEDIR)/$(check_p_subdir)
+ -@(rootme=`${PWD_COMMAND}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
if [ -n "$(check_p_subno)" ] \
&& [ -n "$$GCC_RUNTEST_PARALLELIZE_DIR" ] \
Re: [PATCH] gcc parallel make check
On 09/22/2014 11:58 AM, Jakub Jelinek wrote:
LGTM (though, supposedly we want similar change in
libstdc++-v3/testsuite/Makefile.am).
Or, if people would really like to see the commands, we could print them
just once, using e.g.
-$(if $(check_p_subno),@)(rootme= ...
(then e.g. check-parallel-gcc goal would print the command, but
check-parallel-gcc-1 or check-parallel-gcc-112 would not).
So, like this?
commit c750897381a3f936e27cabd825cfa85ce936a6a9
Author: Jason Merrill
Date: Mon Sep 22 11:44:00 2014 -0400
gcc/
* Makefile.in (check-parallel-%): Add @.
libstdc++-v3/
* testsuite/Makefile.am (%/site.exp): Add @.
(check-DEJAGNU): Likewise.
* testsuite/Makefile.in: Regenerate.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 6f251a5..97b439a 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3674,10 +3674,10 @@ $(lang_checks_parallelized): check-% : site.exp
fi
check-parallel-% : site.exp
- -test -d plugin || mkdir plugin
- -test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
- test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir $(TESTSUITEDIR)/$(check_p_subdir)
- -(rootme=`${PWD_COMMAND}`; export rootme; \
+ -@test -d plugin || mkdir plugin
+ -@test -d $(TESTSUITEDIR) || mkdir $(TESTSUITEDIR)
+ @test -d $(TESTSUITEDIR)/$(check_p_subdir) || mkdir $(TESTSUITEDIR)/$(check_p_subdir)
+ -$(if $(check_p_subno),@)(rootme=`${PWD_COMMAND}`; export rootme; \
srcdir=`cd ${srcdir}; ${PWD_COMMAND}` ; export srcdir ; \
if [ -n "$(check_p_subno)" ] \
&& [ -n "$$GCC_RUNTEST_PARALLELIZE_DIR" ] \
diff --git a/libstdc++-v3/testsuite/Makefile.am b/libstdc++-v3/testsuite/Makefile.am
index e206aba..b4c9e85 100644
--- a/libstdc++-v3/testsuite/Makefile.am
+++ b/libstdc++-v3/testsuite/Makefile.am
@@ -91,9 +91,9 @@ new-abi-baseline:
${extract_symvers} ../src/.libs/libstdc++.so $${output})
%/site.exp: site.exp
- -test -d $* || mkdir $*
+ -@test -d $* || mkdir $*
@srcdir=`cd $(srcdir); ${PWD_COMMAND}`;
- objdir=`${PWD_COMMAND}`/$*; \
+ @objdir=`${PWD_COMMAND}`/$*; \
sed -e "s|^set srcdir .*$$|set srcdir $$srcdir|" \
-e "s|^set objdir .*$$|set objdir $$objdir|" \
site.exp > $*/site.exp.tmp
@@ -115,7 +115,7 @@ $(check_DEJAGNU_normal_targets): check-DEJAGNUnormal%: normal%/site.exp
# Run the testsuite in normal mode.
check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
- AR="$(AR)"; export AR; \
+ $(if $*,@)AR="$(AR)"; export AR; \
RANLIB="$(RANLIB)"; export RANLIB; \
if [ -z "$*" ] && [ "$(filter -j, $(MFLAGS))" = "-j" ]; then \
rm -rf normal-parallel || true; \
diff --git a/libstdc++-v3/testsuite/Makefile.in b/libstdc++-v3/testsuite/Makefile.in
index 59060b8..0fc26f4 100644
--- a/libstdc++-v3/testsuite/Makefile.in
+++ b/libstdc++-v3/testsuite/Makefile.in
@@ -553,9 +553,9 @@ new-abi-baseline:
${extract_symvers} ../src/.libs/libstdc++.so $${output})
%/site.exp: site.exp
- -test -d $* || mkdir $*
+ -@test -d $* || mkdir $*
@srcdir=`cd $(srcdir); ${PWD_COMMAND}`;
- objdir=`${PWD_COMMAND}`/$*; \
+ @objdir=`${PWD_COMMAND}`/$*; \
sed -e "s|^set srcdir .*$$|set srcdir $$srcdir|" \
-e "s|^set objdir .*$$|set objdir $$objdir|" \
site.exp > $*/site.exp.tmp
@@ -566,7 +566,7 @@ $(check_DEJAGNU_normal_targets): check-DEJAGNUnormal%: normal%/site.exp
# Run the testsuite in normal mode.
check-DEJAGNU $(check_DEJAGNU_normal_targets): check-DEJAGNU%: site.exp
- AR="$(AR)"; export AR; \
+ $(if $*,@)AR="$(AR)"; export AR; \
RANLIB="$(RANLIB)"; export RANLIB; \
if [ -z "$*" ] && [ "$(filter -j, $(MFLAGS))" = "-j" ]; then \
rm -rf normal-parallel || true; \
Re: Towards GNU11
On 10/09/2014 08:45 AM, Matthias Klose wrote: What happened to the plans to stabilize the libstdc++ c++11 ABI? Is this still a target for GCC 5? Yes. Jason
Re: [Consult] g++: About "-Wunused-variable" for constant variable initialized by function
On 10/12/2014 10:32 AM, Chen Gang wrote:
[root@localhost qemu_cc]# cat test.cc
const char n() { return 1; }
const char c = n();
[root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O0 -c -o test.o test.cc
[root@localhost qemu_cc]# /usr/local/bin/g++ -Wall -O2 -c -o test.o test.cc
test.cc:2:12: warning: 'c' defined but not used [-Wunused-variable]
const char c = n();
^
The warning is correct (and new). Please submit bug reports via the
website; see https://gcc.gnu.org/bugs/
Jason
Re: Account creation disabled on GCC Bugzilla
What should I tell a user who wants to create an account? Jason
Re: Enabling -fextended-identifiers by default
On 11/03/2014 10:24 AM, Joseph Myers wrote: I propose enabling -fextended-identifiers by default for the appropriate standard versions (i.e. all C++ versions, C99 and above for C - so enabled by default for C now the default C version is gnu11). Any comments or objections? Yes, I've been thinking that we should do that. Jason
Re: C++ FE relying on not folding stuff for constexprs?
On 11/04/2014 09:11 AM, Richard Biener wrote: I have no idea how I can keep the testcase working - to me it seems it works by accident. So I am inclined to XFAIL it (it's an accept-invalid then). OK. Jason
Re: GCC 5.0 Status Report (2014-11-03), Stage 1 ends Nov 15th
On 11/03/2014 04:18 AM, Jakub Jelinek wrote: What larger merges are still planned for GCC 5? I'm planning to merge the concepts branch. Jason
Re: Query about the TREE_TYPE field
On 11/18/2014 09:26 AM, Andrew MacLeod wrote:
I was poking around attribs.c while trial running my tree-type-safety
stuff, and it triggered something in decl_attributes() that seems fishy
to me. It looks like it was part of the fix for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35315
decl_attributes() can be passed a tree node which is either decl or a
type, but we get to this little snippet:
if (spec->type_required && DECL_P (*anode))
{
anode = &TREE_TYPE (*anode);
/* Allow ATTR_FLAG_TYPE_IN_PLACE for the type's naming decl. */
if (!(TREE_CODE (*anode) == TYPE_DECL
&& *anode == TYPE_NAME (TYPE_MAIN_VARIANT
(TREE_TYPE (*anode)
flags &= ~(int) ATTR_FLAG_TYPE_IN_PLACE;
}
anode is changed to point to the TREE_TYPE of the original decl, and
*then* checks if it is a TYPE_DECL... That doesnt seem right to me..
we can't have a TYPE_DECL as a TREE_TYPE can we?
No.
is that code suppose to be checking is the original DECL is a TYPE_DECL
rather than the TREE_TYPE?
I think so.
Maybe the assignment to anode should be after the if instead of in front
of it?
Probably.
Strange that the 35315 patch fixed the testcase with that change being a
placebo...
Jason
Re: Query about the TREE_TYPE field
On 11/18/2014 02:32 PM, Andrew MacLeod wrote: So it effectively does nothing. Unless Jason can think of a good reason for it, we probably ought to turf it. Its effectively a NOP. Yeah, go ahead. Jason
Re: [RFC] Dealing with ODR violations in GCC
On 02/16/2015 07:27 PM, Jan Hubicka wrote: Jason, I wonder if there is more informative way to print destructor during LTO than as __comp_dtor? You could print the mangled name, and possibly run it through __cxa_demangle if it starts with _Z. Laos for named types, perhaps printing just type name instead of the wrong "struct typename" (because we make no difference between struct and class at LTO) would be cleaner. That makes sense. Jason
Re: [debug-early] emitting early debug for external variables
If you move the call to rest_of_decl_compilation we could go through and prune the debug info for unused decls at dwarf2out_finish time, the way we do with unused types. Jason
Atomic operations and unaligned memory
The wiki page https://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy says, --- typedef char B3[3]; _Atomic B3 obj2; An object will be promoted up to the next lock-free size in order to enable lock free operations, as long as it isn't already a documented lock free size. So obj2 will be promoted to a 4 byte object with whatever alignment is required in order to enable lock-free operations. --- But the implementation doesn't follow this. First, the above is rejected due to applying _Atomic to an array type. If we wrap the array in a struct, the resulting atomic object still has size 3 and alignment 1. Did the design change, or is this a bug? Jason
Change to C++11 by default?
I think it's time to switch to C++11 as the default C++ dialect for GCC 6. Any thoughts? Jason
Re: Passsing unfinished types to gen_type_die_with_usage
On 05/14/2015 10:29 AM, Jan Hubicka wrote: Is it expected & safe for dwarf2out to process unfinished types? Yes, they are treated as an incomplete forward declaration. It seems to me that we may wan to delay rest_of_type_compilation for time the contexts are finished, to.. I wouldn't complain about that, but it doesn't seem necessary. I don't think you want to check TYPE_BINFO if !COMPLETE_TYPE_P. Jason
Re: GCC 5.1.1 Status Report (2015-06-22)
I'm interested in your thoughts on fixing c++/65945 in 5.2. It's trivial to fix the alignment of nullptr_t, but I was concerned about ABI impact. On further research it seems that it won't cause any trouble with argument alignment, since that doesn't seem to rely on TYPE_ALIGN at all; I think the only ABI breakage would come from unaligned nullptr_t fields in classes, which I expect to be very rare. The testcases that were breaking on SPARC and ARM without this fix have to do with local stack slots, which are not part of an interface. So I think we can change this without breaking a significant amount of code, and better to break it now than after we've settled into the new library ABI. We should certainly mention it prominently in the release notes if we do, and I've added a -Wabi warning for the field alignment change. Does this make sense to you? Jason
Re: Elementary question about complete_type vs tsubst_flags_t
On 07/10/2015 07:26 AM, Paolo Carlini wrote: I have an old question about an issue which I noticed a while ago, and for example clearly shows up in c++/62085: in a few places in pt.c we call complete_type from functions getting a tsubst_flags_t. Clearly, complete_type often calls instantiate_class_template_1, which, in turn, often calls tsubst with an hard-coded tf_error. Thus possible errors coming from an initial tf_none. Yep. Those errors are outside the "immediate context" of the substitution, so SFINAE doesn't apply to them. In C++ we don't back out of a class instantiation. Jason
Re: Elementary question about complete_type vs tsubst_flags_t
On 07/10/2015 09:52 AM, Paolo Carlini wrote: Good. Thus in practice the "immediate context" theory boils down to those irrevocable instantiations, that wasn't completely clear to me, thanks. Right. Does that imply that c++/62085 should be closed? I think so, yes. The compilers I have here aren't all in agreement: EDG rejects the testcase like GCC but recent clangs don't, likewise SolarisStudio. Well, the standard gives implementations some latitude to avoid instantiations if it can figure out another way to determine the winning candidate: see 14.7.1p7. I don't know if that's the basis for the difference. Jason
Moving to git
I hear that at Cauldron people were generally supportive of switching over to git as the primary GCC repository, and talked about me being involved in that transition. Does anyone have more information about this discussion? Our current workflow translates over to a git master pretty easily: basically, in the current git-svn workflow, replace git svn rebase and git svn dcommit with git pull --rebase and git push. It should be pretty straightforward to use the existing git mirror as the master repository; the main adjustment I'd want to make is rewriting the various subdirectory branches to be properly represented in git. This is straightforward, but we'll want to stop SVN commits to subdirectory branches shortly before the changeover. It would be good to have a more explicit policy on branch/tag creation, rebasing, and deletion in the git world where branches are lighter weight and so more transient. Jason
Re: Moving to git
On 08/20/2015 02:23 PM, Jeff Law wrote: I suspect Jakub will strongly want to see some kind commit hook to associate something similar to an SVN id to each git commit to support his workflow where the SVN ids are associated with the compiler binaries he keeps around for very fast bisection. I think when we talked about it last year, he just needs an increasing # for each commit, presumably starting with whatever the last SVN ID is when we make the change. Jakub: How about using git bisect instead, and identify the compiler binaries with the git commit sha1? It would be good to have a more explicit policy on branch/tag creation, rebasing, and deletion in the git world where branches are lighter weight and so more transient. Presumably for branch/tag creation the primary concern is the namespace? I think if we define a namespace folks can safely use without getting in the way of the release managers we get most of what we need. ISTM that within that namespace, folks ought to have the freedom to use whatever works for them. If folks want to create a transient branch, push-rebase-push on that branch, then later remove it, I tend to think, why not let them. Makes sense. Do we want a namespace for branches which are perhaps not as transient in nature, ie longer term projects, projects on-ice or works-in-progress that we don't want to lose? Currently such branches are at the top level, but I think it would make sense to categorize them more, including moving many existing branches into subdirectories indicating that they were either merged or abandoned. We might want to delete some old branches entirely. As far as the trunk and release branches, are there any best practices out there that we can draw from? Obviously doing things like push-rebase-push is bad. Presumably there's others. Absolutely, a non-fast-forward push is anathema for anything other people might be working on. The git repository already prohibits this; people that want to push-rebase-push their own branches need to delete the branch before pushing again. There are many opinions about best practices, but I don't think any of them are enough better than what we already do to justify a change. 'git help workflow' describes how development of git itself works: they have "maint", "master" and "next" branches that would roughly correspond to our latest release branch, trunk, and next-stage-1-trunk. Having a "next" branch could be useful, but I think we deliberately don't have one currently in order to focus people on release preparation during stage 3 rather than it always being stage 1 somewhere. One interesting thing that they do is to keep earlier branches merged into later branches, so 4.9 into 5, 5 into trunk, trunk into next. This is an interesting discipline, but I'm not sure it is of much practical value. Jason
Re: Moving to git
On 08/20/2015 03:31 PM, David Malcolm wrote: On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote: I hear that at Cauldron people were generally supportive of switching over to git as the primary GCC repository, and talked about me being involved in that transition. Does anyone have more information about this discussion? Our current workflow translates over to a git master pretty easily: basically, in the current git-svn workflow, replace git svn rebase and git svn dcommit with git pull --rebase and git push. It should be pretty straightforward to use the existing git mirror as the master repository; the main adjustment I'd want to make is rewriting the various subdirectory branches to be properly represented in git. This is straightforward, but we'll want to stop SVN commits to subdirectory branches shortly before the changeover. It would be good to have a more explicit policy on branch/tag creation, rebasing, and deletion in the git world where branches are lighter weight and so more transient. If we're going to migrate to git (I hope so), can we also please *slightly* revise the policy on commit messages, to add meaningful titles to commits? Currently: https://www.gnu.org/software/gcc/svnwrite.html#checkin says: "The log message for that checkin should be the complete ChangeLog entry for the change." and the subsection "Commit the changes to the central repository" below https://www.gnu.org/software/gcc/svnwrite.html#example has an example showing this. In the git world, the first line of the commit message has special meaning, being treated as the "title" of the commit. Quoting the git docs [1]: "Though not required, it’s a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. The text up to the first blank line in a commit message is treated as the commit title, and that title is used throughout Git. For example, git-format-patch[1] turns a commit into email, and it uses the title on the Subject line and the rest of the commit in the body." For gcc, I suggest that the first line of the commit message should be a representative title, typically the "Subject" line of the relevant gcc-patches thread (without any "[PATCH]" prefix), and this should be followed by the ChangeLog entry as before as the "more thorough description" that the git docs speak of. Sounds good to me. Looking at the commit history, many contributors appear to be already applying this policy when committing to svn (I'm one of them); it makes the history much easier to read from git (otherwise the title is typically something like "gcc/" or just a datestamp and email, which isn't as helpful). Try running "git shortlog" on a git mirror of the current repo to see what I mean. For example: https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=227033 which when viewed from git has the title: "[ARM] Hide existing float16 intrinsics unless we have a scalar __fp16 type". I'm merely proposing doing this going forward, *not* to attempt any kind of retroactive history-editing (ugh). I can write it up for the website if people agree it's a good policy. Hope this is constructive. Dave [1] http://git-scm.com/docs/git-commit (see "DISCUSSION")
Re: Moving to git
On 08/20/2015 04:22 PM, paul_kon...@dell.com wrote: Let's make sure the procedures that people are supposed to follow are clearly documented. I recently went looking for the equivalent in the binutils/gdb project and it doesn't seem to be written down there, though if you ask enough questions on the mailing list you do get some answers. Do you have pointers to relevant email threads? Jason
Re: Moving to git
On 08/20/2015 04:33 PM, Joseph Myers wrote: On Thu, 20 Aug 2015, Jason Merrill wrote: It should be pretty straightforward to use the existing git mirror as the master repository; the main adjustment I'd want to make is rewriting the I think using the existing git mirror for this is a bad idea. To quote <http://esr.ibiblio.org/?p=6778>: "Use git-svn for live gatewaying if you must, remaining aware that it is not the safest tool in the world. But for a full conversion use a dedicated importing tool.". I think a proper conversion to git as the master repository should reconvert all the history with author ids properly mapped and subdirectory branches properly handled as such throughout the conversion. (I don't think other oddities are worth cleaning up unless it's easy to e.g. clean up cvs2svn oddities in the conversion process, or unless someone is particularly keen on cleaning them up, and don't think any attempt should be made to rewrite existing commit messages. And if using reposurgeon, I think its special handling of svn:ignore and .cvsignore should be disabled, keeping .cvsignore in older history and our existing .gitignore in newer history as we already have a well-maintained .gitignore file - that way maybe git tags can keep contents identical to the corresponding SVN tags.) The two histories could then be combined in a single git repository by renaming all the existing refs in the git repository not to conflict with those from the proper conversion, and if desired adding a merge commit on master to converge the two histories. The two histories would share blob objects and hopefully tree objects as well (but of course not commit objects), so this shouldn't increase the space taken up by too much. Thanks for the pointers, that all makes sense. It would be good to have a more explicit policy on branch/tag creation, rebasing, and deletion in the git world where branches are lighter weight and so more transient. In general, we should have updated versions of all documentation relating to the use of the repository (that's mainly svn.html and svnwrite.html), and of scripts in maintainer-scripts, before doing the final move. Yes. * Policy on commit messages, as already discussed (though I'd say that generally the substantive part of the gcc-patches message about the patch is useful to include as well as the ChangeLog entry). (This policy would only be for master and official release branches; for other branches it would be up to the people using them.) Agreed. * As standard for shared repositories, hooks should disallow any non-fast-forward pushes (this means you can't rebase and then push to the same branch without deleting it in between). Yes, this is already the case for the git-svn mirror. * Decide whether to allow branch deletion. If so, I'd say it should only be for branches inside personal / company namespaces. (If a branch is simply obsolete, don't remove it.) This is also currently the policy of the git-svn mirror. * Do we want the hooks disallowing trailing whitespace on new / modified lines? (I'd be inclined to say yes.) I'm not sure how many people would care about this without git nagging them, but sure. * Do we want hooks to send diffs to gcc-cvs as well as commit messages? (binutils-gdb uses hooks that do that with size limits on the amount of diffs sent.) I don't read gcc-cvs, so I don't have an opinion about this. I wouldn't expect it to be useful, but presumably binutils-gdb have a reason for doing it. * In the common case where you try to push a commit and find that someone else committed to master so the push fails, you should git pull --rebase rather than plain git pull before pushing again, so the history on master remains linear in such cases; merge commits on master, if any, should be limited to merges of more substantial development branches. Absolutely. * Specifically do not associate any changes in workflow with the move to git. Exactly the same release branching and development arrangements would be used, ChangeLog files would continue to be updated manually. If someone wishes to (say) set up arrangements for generating ChangeLogs at release time rather than putting entries in them at commit time, that should be something completely separate after the move to git. Agreed. * Make sure whatever process updates the github mirror is kept going after the conversion (actually it looks like it broke two weeks ago...). I have no idea how this mirror is updated. Its github page is remarkably uninformative. * I encourage using the wwwdocs repository as a test-bed for the conversion. Its history is so much simpler that once you have the author map worked out, almost any tool would probably produce a good conversion, and such a conversion could be used to test hooks before converting the main repository. (I expect in any ca
Re: Moving to git
On 08/20/2015 06:32 PM, Segher Boessenkool wrote: On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote: If we're going to migrate to git (I hope so), can we also please *slightly* revise the policy on commit messages, to add meaningful titles to commits? Currently: https://www.gnu.org/software/gcc/svnwrite.html#checkin says: "The log message for that checkin should be the complete ChangeLog entry for the change." and the subsection "Commit the changes to the central repository" below https://www.gnu.org/software/gcc/svnwrite.html#example has an example showing this. In the git world, the first line of the commit message has special meaning, being treated as the "title" of the commit. It would be nice if we could use a real commit message, not just a short title line; for example, people who prepare their patches in git already have that, and use it with format-patch as you say. I think that's what David was suggesting; a short title line, followed by a blank line, followed by a more substantive commit message. This change doesn't need to be tied to the git transition; it could happen either before or after. And many bonus points if we don't have to repeat the changelog in the commit message (it's in the commit already, the bugzilla hook could just pull it from out there). Or we could have another discussion about if we want to have changelogs at all... That's a good question, but I think it's definitely independent. Jason
Re: Moving to git
On 08/21/2015 04:26 AM, Richard Biener wrote: On Thu, Aug 20, 2015 at 10:09 PM, Jason Merrill wrote: ISTM that within that namespace, folks ought to have the freedom to use whatever works for them. If folks want to create a transient branch, push-rebase-push on that branch, then later remove it, I tend to think, why not let them. Makes sense. Well, I think that all public branches should follow the trunk model - if only to make merging a dev branch to trunk possible without introducing messy history. All shared branches, yes, but I think personal branches can be more volatile. Can we limit the namespace one can create branches in? Like force all branches created by $user to be in namespace $user? So require some super-powers to create a toplevel branch? We can. And make [user branches] not automatically pulled? We can't control what 'git clone' pulls by default. People can clone with --single-branch to get just the trunk and then adjust what else gets pulled, but I think it will make most sense for most people to pull everything. Jason
Re: Moving to git
On 08/21/2015 09:47 AM, H.J. Lu wrote: On Fri, Aug 21, 2015 at 6:37 AM, Ramana Radhakrishnan wrote: On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely wrote: On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote: Absolutely, a non-fast-forward push is anathema for anything other people might be working on. The git repository already prohibits this; people that want to push-rebase-push their own branches need to delete the branch before pushing again. On the FSF trunk and the main release branches - I agree this is a complete no-no. A push-rebase-push development model is possible / may be useful when the developers collaborating on that branch agree on that model. Teams following a different model could use a separate repo shared by those developers, not the gcc.gnu.org one. It's much easier to do that with git. Yes you are right they sure can, but one of the reasons that teams are doing their development on a feature branch is so that they can obtain feedback and collaborate with others in the community. People wanting to adopt more aggressive uses of git should be allowed to do so in their private branches as long as they are not able to mess up the official branches in the repository. If there is no way to have some branches in a repo allow rebasing and others not, that's fine but I'd like to know that's the case. Adopting restrictions on the official branches is quite right (list below not extensive but it sounds like) ... a. no rebase / rewriting history That is, all pushes to official branches must be fast-forward. b. no git merges from feature branches. I think that's right at least initially, but I would note that git merge --squash doesn't count as a merge for this rule and is indeed the recommended way to merge a feature branch. Jason
Re: Moving to git
On 08/21/2015 11:26 AM, Joseph Myers wrote: On Fri, 21 Aug 2015, H.J. Lu wrote: Can we enforce that "git bisect" must work on official branches? I think a good principle independent of moving to git is that commits should be bisectable. In particular, if a patch series is committed as separate commits, each commit should be intended to leave the tree in a working state; if a change was split up purely for review purposes rather than with each subset 1-N of the patches intended to leave a working tree, combine the changes before committing. Yes. But if there was a merge from a feature branch that doesn't achieve this (as I expect many don't, in early WIP stages), then you can tell bisect to avoid descending into other branches. https://stackoverflow.com/questions/5638211/how-do-you-get-git-bisect-to-ignore-merged-branches Jason
Re: Moving to git
On 08/21/2015 11:30 AM, Ramana Radhakrishnan wrote: My query was whether allowing for rebase (rewriting history) in published feature branches was a decision to be left to the branch maintainers or was this going to be a repository wide restriction. It also seems odd to me that trunk follows a (manual) fast-forward / rebase and apply kind of development workflow while feature development branches cannot maintain these in terms of without jumping through hoops. I would expect feature branches to merge from trunk when needed during development. When merging the feature into trunk the developer can just use git merge --squash and then decide whether to commit it in one hunk or several. Jason
Re: Moving to git
On 08/21/2015 10:38 AM, Andreas Schwab wrote: Jason Merrill writes: On 08/21/2015 04:26 AM, Richard Biener wrote: Can we limit the namespace one can create branches in? Like force all branches created by $user to be in namespace $user? git will create new namespaces for its own purpose in the future. If you allow arbitrarily named namespaces clashes will happen. I had been thinking of "namespace" as a subdirectory of refs/heads. But now I see that there is something called "namespace" in git. Where did you see that git was going to claim certain namespace names? git help namespaces doesn't suggest anything like that. We can't control what 'git clone' pulls by default. close pulls everything below refs/heads by default. Yes; my point was that you can't change that except with --single-branch. But if we encourage people to use personal git namespaces, then they won't be under refs/heads, so they won't be pulled by default. Jason
Re: Moving to git
On 08/21/2015 02:28 PM, Andreas Schwab wrote: Jason Merrill writes: I would expect feature branches to merge from trunk when needed during development. When merging the feature into trunk the developer can just use git merge --squash and then decide whether to commit it in one hunk or several. This will of course lose the history of the feature branch. Yep. Merging vs. squashing is a subject of debate. Keeping the history of the feature branch is both a pro and a con: it feels bad to throw away history, but keeping it makes both browsing and bisecting more complicated. Hmm, it occurs to me that a squash commit (or series of commits) followed by a merge -s ours could have the advantages of both approaches: the patches land on trunk in a sensible order, but the history is available. I wonder if that avoids the bisect complications? Jason
Re: Moving to git
On 08/21/2015 03:21 PM, Andreas Schwab wrote: Jason Merrill writes: Hmm, it occurs to me that a squash commit (or series of commits) followed by a merge -s ours could have the advantages of both approaches: the patches land on trunk in a sensible order, but the history is available. That would be worse, since changes are duplicated. How duplicated? The non-squash merge would make no changes, only express that the branch is now merged. Jason
Re: Moving to git
On 08/21/2015 04:10 PM, Joseph Myers wrote: On Fri, 21 Aug 2015, Jason Merrill wrote: On 08/21/2015 10:38 AM, Andreas Schwab wrote: Jason Merrill writes: On 08/21/2015 04:26 AM, Richard Biener wrote: Can we limit the namespace one can create branches in? Like force all branches created by $user to be in namespace $user? git will create new namespaces for its own purpose in the future. If you allow arbitrarily named namespaces clashes will happen. I had been thinking of "namespace" as a subdirectory of refs/heads. But now I That's my assumption - all refs (including renamed ones from the old git-svn history) are under refs/heads or refs/tags, users / companies may use subdirectories under there, all refs get pulled by default. (And I don't think we should try to limit branch creation; if anyone wants to create a project branch shared by multiple users, they should be able to do so and not need to put it under a user directory.) I lean that way as well. We should also talk about a policy for when we delete branches; there are a bunch of ancient feature and testing branches in SVN that I think are no longer interesting. Jason
Re: Moving to git
On 08/21/2015 06:44 PM, Mikhail Maltsev wrote: On 08/20/2015 11:09 PM, Jason Merrill wrote: Absolutely, a non-fast-forward push is anathema for anything other people might be working on. The git repository already prohibits this; people that want to push-rebase-push their own branches need to delete the branch before pushing again. There are many opinions about best practices, but I don't think any of them are enough better than what we already do to justify a change. Regardless of what the non-fast-forward-push policy will be (please don't get me wrong - I'm not trying to meddle into development of policies), Feel free to meddle. :) why is deleting and pushing a branch again better than pushing with force? The effect is the same but it's less convenient, so it discourages people from doing it without considering whether that's really the right thing to do. But I'm flexible on this point. Jason
Re: [PATCH][www] svnwrite.html: recommend giving checkin messages a title (was Re: Moving to git)
On 08/21/2015 07:54 PM, David Malcolm wrote: Here's an actual check-in session for a patch John Carr recently Can this really be described as an actual check-in session when we're changing the contents? :) Jason
Re: Moving to git
On 08/24/2015 11:49 AM, Jeff Law wrote: On 08/24/2015 09:43 AM, Jakub Jelinek wrote: Not to mention we should keep the existing r123456 comments in bugzilla working, and I'm not convinced keeping a SVN version of the repository (frozen) for that purpose is the best idea. I'd like to keep the old ones working, but new references should probably be using the hash id and commit name. As for how to best keep the old r123456 links working, I don't know. Presumably those could be mapped behind the scenes to a git id. git-svn find-rev takes r123456 and returns a commit hash based on the git-svn-id in the git log; I don't see why we would need to break that moving forward, though I'm not sure how well it would work without reference to an actual SVN server. Jason
Re: Moving to git
On 08/24/2015 11:54 AM, Richard Earnshaw wrote: Why not use the output of 'git show -s --format=%ct-%h'? $ git show -s --format=%ct-%h master 1440153969-f57da59 That gives you a unix timestamp for the commit, followed by the hash. Now you've got a fully ordered way of referring to the commit, but still have access to the hash code. You don't even need to worry about the hash code, you can use the timestamp by itself. Given the timestamp, git log -1 --until 1440153969 will show you the relevant commit, or git rev-list HEAD --max-count=1 --until 1440153969 will give you the hash. So that seems like a suitable monotonically increasing identifier. What do you think, Jakub? Jason
Re: Offer of help with move to git
First, thanks a lot for the offer of help; I'm happy to take you up on it rather than do it all myself. On 08/24/2015 12:54 PM, Joseph Myers wrote: FWIW, Jason's own trial conversion with reposurgeon got up to at least 45GB memory consumption on a 32GB repository. It ended up being about 65GB. Fortunately I regularly use a machine with 128GB, so that isn't a big deal. And the trial conversion took less than a day; I didn't get an exact time. I'd like to use the --legacy flag so that old references to SVN commits are easier to look up. --- With respect to Joseph's point about periodic deletion and re-creation of branches, it looks like reposurgeon dutifully models them as deletion and re-creation of the entire tree, which is understandable but not ideal. It also warns about these with, e.g., reposurgeon: mid-branch deleteall on refs/heads/master at <184996>. Looking over the instances of this warning, it seems that in most cases it was branch maintainers deciding to blow away the entire branch and start over because svn mergeinfo had gotten too confused. I think in all of these cases the right thing is to pretend that the delete/recreate never happened. --- Unfortunately, it looks like reposurgeon doesn't deal with gcc SVN's subdirectory branches any better than git-svn. It does give a diagnostic about them: reposurgeon: branch links detected by file ops only: branches/suse/ branches/apple/ branches/st/ branches/gcj/ branches/csl/ branches/google/ branches/linaro/ branches/redhat/ branches/ARM/ tags/ix86/ branches/ubuntu/ branches/ix86/ though this is an incomplete list. There are also also branches/ibm, branches/dead, tags/apple, tags/redhat, tags/csl, and tags/ubuntu. Ideally the conversion tool would just recognize that these are subdirectories containing branches rather than branches themselves. Neither git-svn nor reposurgeon currently do that, they both just treat them as one big branch. This is easy enough to fix after the fact with git filter-branch: https://gcc.gnu.org/wiki/GitMirror#Subdirectory_branches but you might want to improve reposurgeon to handle this pattern directly. Jason
Re: Offer of help with move to git
On 08/28/2015 12:13 AM, Eric S. Raymond wrote: With respect to Joseph's point about periodic deletion and re-creation of branches, it looks like reposurgeon dutifully models them as deletion and re-creation of the entire tree, which is understandable but not ideal. It also warns about these with, e.g., reposurgeon: mid-branch deleteall on refs/heads/master at <184996>. Looking over the instances of this warning, it seems that in most cases it was branch maintainers deciding to blow away the entire branch and start over because svn mergeinfo had gotten too confused. I think in all of these cases the right thing is to pretend that the delete/recreate never happened. Perhaps, but there be dragons here. Without those deletealls you could easily end up with incorrect head-revision content. Before you try anything clever here, examine the final repo state to see whther it looks like "the delete/recreate never happened" - it very well might. It looks like that for all the ones I've looked at, but I guess I can look through all of them. I'm not sure how squashing the delete/recreate together could change head content. Unfortunately, it looks like reposurgeon doesn't deal with gcc SVN's subdirectory branches any better than git-svn. It does give a diagnostic about them: reposurgeon: branch links detected by file ops only: branches/suse/ branches/apple/ branches/st/ branches/gcj/ branches/csl/ branches/google/ branches/linaro/ branches/redhat/ branches/ARM/ tags/ix86/ branches/ubuntu/ branches/ix86/ though this is an incomplete list. There are also also branches/ibm, branches/dead, tags/apple, tags/redhat, tags/csl, and tags/ubuntu. Ideally the conversion tool would just recognize that these are subdirectories containing branches rather than branches themselves. Neither git-svn nor reposurgeon currently do that, they both just treat them as one big branch. This is easy enough to fix after the fact with git filter-branch: https://gcc.gnu.org/wiki/GitMirror#Subdirectory_branches but you might want to improve reposurgeon to handle this pattern directly. Look closely at branchify_map. I think we may be able to use it to get the effect you want. Aha, I hadn't noticed that yet. I'll give it a try, thanks. Is 'jason' your preferred username everywhere? I'll set up write access to the conversion-machinery repo for you if you like. Yes, thanks. Jason
Re: Action stamps
On 08/26/2015 01:11 PM, Eric S. Raymond wrote: What I usually do with old commit references in comments is map them to what I call an "action stamp" - a user ID followed by an RFC3339 date. While this is theoretically not quite adequate, in practice collisions are rare to nonexistent. For general identification of commits, as with references automatically added to Bugzilla and such, that makes a lot of sense. So in a git format string, %ce and %cI. And we can map back from such a stamp to the commit by specifying --author as well as --until; is that what you do? For Jakub or anyone else wanting a key to associate a file with a commit, they can decide for themselves what date format they want to use and whether to bother with the user id. I would think that if he is only interested in commits on the trunk (and so should use log --first-parent), the timestamp is sufficient. Jason
Re: Action stamps
On 08/29/2015 10:58 AM, Dominique d'Humières wrote:
For Jakub or anyone else wanting a key to associate a file with a commit, they
can decide for themselves
what date format they want to use and whether to bother with the user id. I
would think that if he is only
interested in commits on the trunk (and so should use log --first-parent), the
timestamp is sufficient.
I share Jakub’s concern about having access to an increasing labeling of the
revisions. What would be the replacement of « svn update -r »?
Given git aliases:
stamp = show -s --format='%cI!%ce'
scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ $a != $1 ]; then
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"
smaster = "!f(){ git scommit \"$1\" trunk --first-parent; }; f"
shs = "!f(){ git show $(git smaster $1); }; f"
slog = "!f(){ s=$1; shift; git log $(git smaster $s) $*; }; f"
sco = "!f(){ git checkout $(git smaster $1); }; f"
and an action stamp 2015-08-20T20:55:15Z!jason, then
git sco 2015-08-20T20:55:15Z\!jason
will check out the (most recent) commit with that stamp. It also works
with just the timestamp.
A timestamp gives you a simple increasing (though sparse) label, though
it might not always be unique; when I locally rebase several patches I
sometimes get two or three with the same timestamp, which I expect to be
preserved if I push them upstream.
Jason
Re: Action stamps
On 09/01/2015 05:21 AM, Eric S. Raymond wrote:
Jason Merrill :
Given git aliases:
stamp = show -s --format='%cI!%ce'
scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ $a != $1 ]; then
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"
smaster = "!f(){ git scommit \"$1\" trunk --first-parent; }; f"
shs = "!f(){ git show $(git smaster $1); }; f"
slog = "!f(){ s=$1; shift; git log $(git smaster $s) $*; }; f"
sco = "!f(){ git checkout $(git smaster $1); }; f"
and an action stamp 2015-08-20T20:55:15Z!jason, then
git sco 2015-08-20T20:55:15Z\!jason
will check out the (most recent) commit with that stamp. It also works with
just the timestamp.
This is a corner of git of which I knew not. How does one set this sort of
alias? I Google...
Will git config --global alias.stamp = show -s --format='%cI!%ce
and analogous command lines work?
As Jonathan says, I was editing them directly into the [alias] section
of my ~/.gitconfig .
I think I understand what most of these are doing, but...you would be doing
a service to the world if you wrote a little shellscript that set these up,
with short explanatory comments reveraling what each is to be used for, like
this:
# sco - check out most recent commit with specified action stamp
I'd add that to the reposurgeon distribution in a heartbeat.
Here's an improved version:
# git stamp - print a reposurgeon-style action stamp
stamp = show -s --format='%cI!%ce'
# git scommit - list the most recent commit that
matches .
# Must also specify a branch to search or --all.
scommit = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d -1\"; if [ $a != $1 ]; then
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"
# git scommits - as above, but list all
matching commits.
scommits = "!f(){ d=${1%%!*}; a=${1##*!}; arg=\"--until=$d --after $d\"; if [ $a != $1 ]; then
arg=\"$arg --committer=$a\"; fi; shift; git rev-list $arg ${1:+\"$@\"}; }; f"
# git smaster - list the most recent commit on master that matches
.
smaster = "!f(){ git scommit \"$1\" master --first-parent; }; f"
smasters = "!f(){ git scommits \"$1\" master --first-parent; }; f"
# git shs - show the commits on master that match .
shs = "!f(){ stamp=$(git smasters $1); shift; git show ${stamp:?not found}
$*; }; f"
# git slog - start git log at on master
slog = "!f(){ stamp=$(git smaster $1); shift; git log ${stamp:?not found}
$*; }; f"
# git sco - check out the most recent commit on master that matches
.
sco = "!f(){ stamp=$(git smaster $1); shift; git checkout ${stamp:?not
found} $*; }; f"
Jason
Re: Action stamps
On 09/01/2015 11:59 AM, Eric S. Raymond wrote: Jason Merrill : Here's an improved version: You wrote: # git scommit - list most recent commit that matches . # Must also specify a branch to search or --all. Where must the branch argument appear with respect to the other arguments? After the stamp; otherwise it doesn't matter, it'll just be passed along to git rev-list. Am I correct that this should be applied by creating or appending to an [alias] section in ~/.gitconfig? Yes. Jason
Re: Acceptance criteria for the git conversion
On 09/03/2015 02:59 AM, Trevor Saunders wrote: On Tue, Sep 01, 2015 at 06:06:33PM +0200, Andreas Schwab wrote: "Eric S. Raymond" writes: There is no way to maintain those links for git, so yes, you want to keep a read-only Subversion instance around. The mapping can also be put in some git notes tree for use by bugzilla. That would only need to be set up once. I'd think that would be the way you'd want to associate git commits with a svn commit, but I think bugzilla wants to do the reverse map svn commits to git ones (or we could just rewrite the link targets) but either way that needs a mapping in the other direction. Obviously having a mapping in one direction makes getting the reverse pretty trivial. It's pretty trivial to map from SVN rev numbers to git with either git-svn or reposurgeon --legacy commit decorations. git log --grep '^git-svn-id:.*@1234 ' --all -1 git log --grep '^Legacy-ID: 1234$' --all -1 Jason
GCC branches/st (was Re: Offer of help with move to git)
[David, we're talking about moving the GCC repository to Git, and how to handle subdirectory branches.] On 09/04/2015 12:17 PM, Joseph Myers wrote: branches/st is more complicated than simply being a container for subdirectory branches. It has a README file, five cli* subdirectories that look like branches of GCC, two subdirectories binutils/ and mono-based-binutils/ that are essentially separate projects (this is not of course any problem for git - having a branch sharing no ancestry with other branches is absolutely fine), and a subdirectory tags that contains tags of those various branches (I think). So you want to say: branches/st/tags/* are tags; branches/st/* (subdirectories other than tags/) are branches; branches/st/README I don't know how you should handle (I suppose it could be a branch on its own, that just contains a README file, with commits affecting both README and other branches being split into separate commits to each piece; it is something that's still meaningful after the conversion and that ought to end up in the converted repository in some form). Hmm. The README does complicate things; maybe we should just leave it as a single branch and let interested people choose how to deal with it. David, you were the last committer; any opinions? Jason
Git conversion: disposition of old branches and tags
There are lots of ancient branches and tags in the SVN repository that
are no longer interesting, and it would be nice not to have them
cluttering up the lists and default fetch set.
The options I see for each branch or tag are:
1) Keep them at the same place.
2) Move them to a subdirectory like "dead", as was sometimes done in SVN.
3) Delete them.
4) Move them out of refs/{heads,tags}, perhaps into refs/namespaces/dead
or refs/namespaces/archive.
For release tags and active branches, #1 is obviously the right choice.
I don't think #2 is very useful.
I think #3 is the right choice for the *merge* tags: they are just
artifacts of the difficulty of SVN merges, and I think we should discard
them.
For most old branches and tags, I like #4; that takes them out of the
set that is fetched by default, but keeps the history on the server.
Make sense?
Jason
Re: complex support when using -std=c++11
On 11/15/2015 04:09 PM, D Haley wrote: Thanks for the prompt reply. I am not an expert here, so I probably don't know the correct solution for gcc. We are using std=c++11 to maximise source compatibility for any users seeking to recompile our code on whatever compiler/toolchain they have. Note that _Complex isn't part of C++11, so you shouldn't be using it in code that's intended to be portable to any C++11 implementation. But certainly the current G++ behavior can be improved. Jason
C++ order of evaluation of operands, arguments
There's a proposal working through the C++ committee to define the order of evaluation of subexpressions that previously had unspecified ordering: http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf I agree with much of this, but was concerned about the proposal to define order of evaluation of function arguments as left-to-right, since GCC does right-to-left on PUSH_ARGS_REVERSED targets, including x86_64. Any thoughts? Jason
Re: C++ order of evaluation of operands, arguments
On 11/25/2015 01:25 PM, Martin Sebor wrote:
On 11/24/2015 02:55 AM, Andrew Haley wrote:
On 23/11/15 23:01, Jason Merrill wrote:
There's a proposal working through the C++ committee to define the order
of evaluation of subexpressions that previously had unspecified
ordering:
http://www.open-std.org/Jtc1/sc22/wg21/docs/papers/2015/p0145r0.pdf
I agree with much of this, but was concerned about the proposal to
define order of evaluation of function arguments as left-to-right, since
GCC does right-to-left on PUSH_ARGS_REVERSED targets, including x86_64.
Any thoughts?
Not about PUSH_ARGS_REVERSED targets, but my two-penn'orth:
The proposal seems to be a bit of a minefield. This one:
a(b, c, d)
is a bit counter-intuitive. I wouldn't expect a to be evaluated before
the arg list. I wonder how many C++ programmers would.
The motivating example in the paper suggests that many C++
programmers expect a left to right order of evaluation here
due to the commonality of constructs like chains of calls.
Yes, although chains of calls like
var.fn1(args1).fn2(args2)
are covered by the "a.b" bullet. The above bullet would be more
relevant to a chain like
fn1(args1)(args2)
or
[captures]{...}(args)
Jason
Re: -Wplacement-new on by default
On 12/10/2015 01:00 PM, Martin Sebor wrote:
Jason,
I just want to make sure we still want the -Wplacement-new option
I added some time ago enabled by default.
I think I had initially intended it to be on because the original
implementation was more permissive and didn't diagnose cases where
(for example) the buffer spanned multiple members of the same struct,
as in the example below. After our discussion of the patch where
you pointed out that C++ is moving in the direction of increased
strictness of aliasing requirements, I changed it to diagnose
those cases.
Can you please confirm that enabling -Wplacement-new by default
is still appropriate?
Thanks
Martin
struct S {
int a;
char b;
} s;
new (&s) char [sizeof s]; // accepted
new (&s.a) char [sizeof s]; // diagnosed
I think it's still appropriate to warn about this by default.
Jason
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 02/29/2016 10:13 AM, Michael Matz via cfe-commits wrote: Also this insistence that all of "trivially copyable" is already quite nicely specified in the C++ ABI is still not really relevant because C++ _is not the only language out there_. I'm not sure how often I have to repeat this until people get it. Other language ABIs can handle language specific calling conventions as appropriate for them. The psABI can only talk about things that are in its domain. Jason
Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct
On 03/01/2016 11:43 AM, Michael Matz wrote: Hi, On Mon, 29 Feb 2016, Jason Merrill wrote: Also this insistence that all of "trivially copyable" is already quite nicely specified in the C++ ABI is still not really relevant because C++ _is not the only language out there_. I'm not sure how often I have to repeat this until people get it. Other language ABIs can handle language specific calling conventions as appropriate for them. The psABI can only talk about things that are in its domain. Naturally. How far to follow that road, though? Remove the word "class" from the description of empty types again? Why is that in-domain and the notion of trivially copyable isn't? Yes, dropping "class" seems appropriate, especially since the psABI uses that word to refer to register classes. Jason
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On Thu, Apr 21, 2016 at 12:47 PM, Jason Merrill wrote: > On Thu, Apr 21, 2016 at 11:57 AM, Jonathan Wakely > wrote: >> >> I once tried to write a gcc plugin that would check all names defined >> by libstdc++ and ensure they were either in the reserved namespace, or >> were in a whitelist of allowed names defined by the standard (such as >> "istream" and "read"). It didn't work because gcc plugins don't run >> early enough, so macros and uninstantiated templates are never seen by >> the plugin. > > > Then let's add plugin callbacks to make that possible. Jason
Re: CppCoreGuidelines warnings
On Mon, May 9, 2016 at 5:18 AM, Jonathan Wakely wrote: > On 8 May 2016 at 02:10, Christopher Di Bella wrote: >> Hi all, >> >> I've been tracking gcc-digest for a bit, but would like to be a little >> more involved in the development of gcc. >> >> I haven't been able to find anything about the CppCoreGuidelines in >> gcc -- I'm wondering if there's a warning system in the pipeline that >> I might have missed in the digest thread? If so, great, who do I need >> to contact about helping out? >> >> If not, I'd like to get a start on implementing a warning system for >> them. I'll create a branch, but I doubt it'll be ready for gcc 7.1's >> release. > > Hi, I don't think anyone is working on that yet. > > See https://gcc.gnu.org/contribute.html for some prerequisites to > contributing significant changes to GCC. > > I don't know the status of the static analysis tool the Microsoft were > planning to release, which would do a lot of the checking. To > incorporate the checks into GCC would probably involve changes to both > the C++ front-end and the C++ library, but I would welcome such > changes. As would I. You can coordinate with me about front end changes. Thanks, Jason
Re: CppCoreGuidelines warnings
On Tue, May 17, 2016 at 8:51 AM, Manuel López-Ibáñez wrote: > Please also note that, in terms of legal papers, the FSF is much more > flexible than one may think, but they are not very pro-active or fast > (in my past experience, things may have changed now). If you find some > internal resistance at your company, it would be good to figure out > what are the key issues for your employer and what are the possible > trade-offs, then explain them to the FSF legal team. If there is any > possible solution at all, they will surely find it out. But it would > be better to discuss all possibilities with your employer to avoid > wasteful back and forth. It might work better to put your employer in touch with the FSF so you don't have to mediate in a game of telephone; I believe ass...@gnu.org is the right address to use. Jason
Re: Please, take '-Wmisleading-indentation' out of -Wall
On Mon, May 30, 2016 at 3:15 PM, Patrick Palka wrote: > Though there are some inconsistencies regarding the inclusiveness of > -Wall seeing as neither -Woverlength-strings nor -Wempty-body are > enabled by -Wall even though they seemingly satisfy the criteria of > -Wall more readily than -Wmisleading-indentation does. We certainly don't want -Woverlength-strings in -Wall; that's a pedantic portability warning, not a warning about code that is probably incorrect. There's an open BZ about -Wempty-body, bug 52961. Jason
Re: CppCoreGuidelines warnings
On Sat, Jun 11, 2016 at 8:57 PM, Christopher Di Bella wrote: >> I'm currently waiting on approval from my employer before I move ahead >with anything > > My employer has given me the okay to contribute to gcc, provided that I > follow some fairly straightforward rules. Most of these things are given, > such as "don't contribute to gcc while at work", "don't put work code in your > contributions or vice versa", etc. Of course, my company needs to make it > clear that I understand these rules before I'm given a green light. > >> Note also that if you want to learn the process, small patches do not need >any legal papers > > I'm going to start with a few minor patches, which I refrained from until I > they gave approval, and then move up in the world. > >> You can coordinate with me about front end changes. > > I am hoping you mean compiler front-end (i.e. syntax, semantic, static > analysis, etc.), rather than application front-end (flags, etc.), as > the compiler front-end is the section I'm most interested in contributing to. Yes, that's right. > >> To incorporate the checks into GCC would probably involve changes to ... >the C++ library > > I'm also happy to contribute to both an improved C++ Standard Library and > stdlibc++, but don't want to spread myself too thin (I'm gearing my career for > compiler development, and thus would like to work on the front-end a little > more). Would it be better to work on this before, after, or in parallel with > the > front-end? That's really up to you. If you're most interested in the front end, starting there makes sense. > >> Currently yes, but it was supposed to be released as open source. >> Some of the C++ Core Guidelines checks are already implemented in >clang-tidy: > > Does this mean that in your opinion, we (mostly me) should contribute to > one of those projects instead, or are they just cool projects to watch? They might be interesting to look at, but we'd definitely like to have support for this in GCC. Jason
Re: How to improve the location of a gcc diagnostic
On Thu, Jun 23, 2016 at 5:04 PM, David Malcolm wrote: > Step 10: commit to svn > > Once the patch is approved, commit it to svn. (FWIW I do all of my > development work in git; I have an svn checkout that I use purely for > the final checkin, having smoketested the patch first). Why not checkin using git-svn? I have no svn checkout. Jason
Re: Deprecating basic asm in a function - What now?
On Mon, Jul 4, 2016 at 12:09 PM, Frank Ch. Eigler wrote: > jwakely.gcc wrote: > >> [...] (When we switched Fedora to using GCC 6, with C++14 enabled by >> default, dozens and dozens of C++ packages failed to compile, >> because even in 2016 nobody had ever tried to compile them with >> C++11 features enabled.) > > And one shouldn't blame those that choose to stick with CXXFLAGS=-std=c++98 > instead of porting their code, which after all is working & stable. Absolutely, that's a fine solution. Though often it makes sense to put the -std argument in the CXX variable rather than CXXFLAGS. Jason
Re: style convention: /*foo_p=*/ to annotate bool arguments
On Tue, Oct 4, 2016 at 4:29 PM, Zan Lynx wrote:
> On 10/04/2016 02:00 PM, Martin Sebor wrote:
>> This would have been easier if C++ had allowed the same default value to
>> be given in both the declaration and the definition:
>>
>> void foo(int x, int y, bool bar_p = false);
>>
>> void foo(int x, int y, bool bar_p = false)
>> {
>> }
>
> There is really no point to duplicating it. The default value goes into
> the headers which is what is read by users of the code.
In GCC sources, I think users look at the function definition more
often than the declaration in the header, the latter of which
typically has neither comments nor parameter names.
Jason
Re: style convention: /*foo_p=*/ to annotate bool arguments
On Wed, Oct 5, 2016 at 12:18 PM, wrote: >> On Oct 5, 2016, at 12:12 PM, Jeff Law wrote: >> On 10/04/2016 03:08 PM, Jason Merrill wrote: >>> On Tue, Oct 4, 2016 at 4:29 PM, Zan Lynx wrote: >>> ... >>> In GCC sources, I think users look at the function definition more >>> often than the declaration in the header, the latter of which >>> typically has neither comments nor parameter names. >> So true. One could claim that our coding standards made a fundamental >> mistake -- by having all the API documentation at the implementation rather >> than at the declaration. Sigh > > Yes, though the mistake started in C and C++ which allow declarations with > only types, not names. C++ does allow names, they just haven't been added to GCC headers yet. Jason
Re: Repository for the conversion machinery
On Thu, Oct 6, 2016 at 1:19 PM, Eric S. Raymond wrote: > Joseph Myers : >> On Thu, 6 Oct 2016, Eric S. Raymond wrote: >> >> > I thought the gcc conversion was done. >> > >> > I can make the repository available again if it's needed. >> >> The conversion got stalled (I'm not sure why; maybe just Jason being busy >> with other things) but is still intended (I'm not sure for when), so yes >> the repository is still needed. > > I was unaware of this. I thought Jason had gotten the bit in his teeth > and finished it while I was off doing other things. After I ran into a couple of reposurgeon bugs and didn't hear back from you, I started investigating rewriting the existing git svn mirror with git filter-branch instead. That seems an attractive option, but not long afterward I needed to shift focus to front end development and decided to put off the conversion until the next stage 1. And here we are coming toward the end of that stage 1 and I haven't found time for it yet, and am not likely to before the end of this stage 1. > (I'm sorry for not paying closer attention, but leading the project to fix NTP > has eaten almost all my bandwidth for most of the last two years.) > > What do we do to get this restarted? I'll make the conversion-machinery > repo visible again; what's the step after that? As Joseph mentions, we should update the user map. After that, I had a reposurgeon conversion of the website done apart from the hooks, and could update that and put it in place as a good prelude to converting the sources. We should also reopen discussion of workflow and branch policies. One concern I have about the git conversion is that gcc.gnu.org already refuses git connections fairly frequently due to overloading, and I'm afraid that will become much more common when current SVN users switch over. Jason
Re: Repository for the conversion machinery
On Thu, Oct 6, 2016 at 4:31 PM, Joseph Myers wrote: > On Thu, 6 Oct 2016, Jason Merrill wrote: > >> After I ran into a couple of reposurgeon bugs and didn't hear back >> from you, I started investigating rewriting the existing git svn >> mirror with git filter-branch instead. That seems an attractive >> option, but not long afterward I needed to shift focus to front end > > I've used both git-svn (sometimes with git filter-branch) and reposurgeon > for repository conversions. My experience is that if there's anything at > all complicated or messy about the history, using git-svn for the > conversion is not a good idea, so I don't think that's an attractive > option at all. But we're already using git-svn, and it's fine. Introducing another tool just adds opportunities to be affected by new and different bugs. Specifically, reposurgeon doesn't like subdirectory branches much more than git-svn does, though I was able to work around that with branchify (and some fixes in reposurgeon). It discards branches with no additional commits, and keeps other branches that were deleted in SVN, though I was able to work around this with a postprocessing script. Most significantly, it fails to handle some commits (I noticed r137307 and r131989), leading to incorrect file content at the top of the affected branches. This is the issue that I didn't hear back from Eric about, which led me to consider other approaches. Fortunately it marked them (as well as many others) with emptycommit tags for review. But if you want to do it with reposurgeon, I won't complain. I've pushed my WIP to https://github.com/jicama/gcc-reposurgeon Jason
Re: Repository for the conversion machinery
On Mon, Oct 10, 2016 at 6:38 AM, Jonathan Wakely wrote: > On 7 October 2016 at 22:26, Joseph Myers wrote: >> On Fri, 7 Oct 2016, Frank Ch. Eigler wrote: >>> FWIW, I thought at one point the consensus was that the mailmap would >>> expand only to $use...@gcc.gnu.org rather than $userid@$organization, >>> esp. considering the case where there is no single $organization that >>> accurately covers the whole contribution timespan of the given $userid. >> >> I don't think there was any such consensus (older ids weren't from >> gcc.gnu.org anyway so @gcc.gnu.org would be nonsense for that part of the >> history). >> >> My view is: contributors are free to specify what name and email address >> they want used, but if they want something other than a single name and >> email address for the whole commit history with a given username, it's the >> contributor's responsibility to come up with lists of commits that use >> each mapping rather than a hypothetical recipe based on examining >> ChangeLogs. > > We'd only need to look at the actual ChangeLogs if the commit message > doesn't include a name and email address. And if we just use the > committer, how do we record the author of a change? > > As Richi said a year ago (and my reply was drafted a year ago but not sent) > ... > > On 17 September 2015 at 11:44, Richard Biener wrote: >> Maybe I'm missing sth but apart from the CVS imported revisions each >> SVN revision should contain the actual change plus the changes to the >> ChangeLog files (you can't count on the commit message itself I guess >> as not all people replicate the ChangeLog entries there). > > It's probably a good start though. If the commit message does have: > > -MM-DD John Doe > > then it's probably reliable. If the commit message doesn't have that > (when I'm committing my own work I don't include that line in the > commit message) then look for ChangeLog entries in the commit. > >> There may be cases we can't handle and then doing some commit ID >> mapping might be ok, but I expect 95% of the cases to work out nicely >> so we should preserve what is in the ChangeLog entry (note that we have >> very strict formatting requirement for the authors there). > > Particularly since the ChangeLog entry gives the Author, which is > often not the same as the Committer. Yes, very often they will be different. This processing can, and probably should, be done with git filter-branch after the initial conversion. Jason
Re: style convention: /*foo_p=*/ to annotate bool arguments
On Tue, Oct 11, 2016 at 10:54 AM, Martin Sebor wrote:
> To close the loop on this thread, although there was mild support
> for both of these conventions there were also objections to both,
> including a suggestion for an alternative to the "/*foo_p=*/" style
> that would be preferred by most people who responded.
>
> With that I don't have the sense that there is consensus to adopt
> either style as conventions for GCC code.
>
> Jason and Jeff (and other reviewers), what does this mean for those
> of us submitting patches? Do we discontinue using the "/*foo_p=*/"
> style in the C++ front end or should we train ourselves to remember
> to use it there but nowhere else?
I still like the comments when it's not clear what the arguments mean
without looking at the callee, no matter the type of the argument. I
would be happy with a patch that changed some of the booleans to enums
instead.
Jason
> On 10/03/2016 05:48 PM, Martin Sebor wrote:
>>
>> In a recent review Jason and I discussed the style convention
>> commonly followed in the C++ front end to annotate arguments
>> in calls to functions taking bool parameters with a comment
>> along the lines of
>>
>> foo (1, 2, /*bar_p=*/true);
>>
>> I pointed out to Jason that in another code review, Jeff asked
>> to remove the same comment from the middle-end [1]. In the
>> interest of consistency Jason and I thought I should bring this
>> up for discussion so we can all be clear on whether or not this
>> is something worth standardizing and documenting.
>>
>> As a separate question, in the same discussion I mention to Jason
>> a convention that I myself have found useful where the value of
>> a default argument is indicated in a comment in a function
>> definition that is declared elsewhere to take one, e.g., like so:
>>
>> // In some header:
>> void foo (int, int, bool = -1);
>>
>> // In some .c file:
>> void foo (int x, int y, bool bar_p /* = false */)
>> {
>> ...
>> }
>>
>> Jason thought this would be a good convention. Is there any
>> interest in/support for adopting it?
>>
>> Thanks
>> Martin
>>
>> [1] https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00354.html
>> [2] https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01469.html
>
>
Re: Implementing p0515 - spaceship operator
On Wed, Sep 26, 2018 at 11:00 AM Jason Merrill wrote: > > On Mon, Sep 3, 2018 at 5:04 PM, Tim van Deurzen wrote: > > I must confess that in the last months I've not been able to find much time > > (I do this in my spare time) to work on this. Part of the problem is also > > that my new employer hasn't yet provided a written copyright waiver for the > > FSF, though they have agreed and my contract already works out well in that > > regard. > > Any progress on this? Has this been worked out? We're getting near the end of GCC stage 1, which is the deadline for new features going into the next release, so it would be great to see a patch with whatever you have so far. Jason
Re: Implementing p0515 - spaceship operator
On Sun, Nov 4, 2018 at 11:36 PM Tim van Deurzen wrote: > I've received a lot of good advice from Nathan, but haven't had an > opportunity to apply it yet. I'm happy, however, to show / commit what I > have so far (which covers the parsing of the operator). I've been > working from the git repository until now, but from the mailing list I > gather that this is not the main development RCS yet. How and/or where > would you prefer my changes to be sent to? Just as a patch to the > mailing list or rather as a new branch in the SVN repo? Patches against the git mirror is fine, I haven't touched the svn client in quite a while either. Jason
Re: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire
On Mon, Feb 4, 2019 at 6:06 AM Martin Jambor wrote: > > I have received the following idea for a Google Summer of Code project, > see the quotation from Paul McKenney below (I do not know myself where > exactly it is from). I consider memory consistency models a very tough > topic and so am doubly reluctant to just post it to wiki without having > a mentor for it. On the other hand, with the right mentors it > definitely can be quite a remarkable project with a big potential. > > Paul, this may come as a surprise for you, but would you be willing to > (co-)mentor such a project if there is a student brave enough to > undertake it? > > C++ front-end guys, would you please consider co-mentoring this project > if Paul was willing to do so? I wouldn't expect this project to touch the C++ front-end at all; any compiler work would all be in the middle/back-end. There's some previous discussion of these issues at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448 So I'd suggest pinging Andrew Macleod. Jason > Anybody else interested in getting involved? > > Any other suggestions/comments? > > Thank you very much in advance, > > Martin > > > Start of forwarded message > > Hi Martin, > > I don't think I have a mentor for this yet though I wonder if Paul McKenney > could be persuaded for this from the memory model side and someone familiar > with the C++ frontend on the GCC side ? > > > -- > > One could argue that compilers in fact implement the C and C++ > memory_order_consume facility. However, all known compilers do so by > promoting it to memory_order_acquire, which on weakly ordered systems > can result in unnecessary memory-barrier instructions on your fastpaths, > which might not be what you want. The reason for the promotion to > memory_order_acquire is the difficutlies faced by compiler writers when > attempting to trace dependencies at the C/C++ source-code level. In fact, > there is a proposal to temporarily deprecate memory_order_consume [1]. > > So what is to be done? One proposal [2] restricts dependency chains > to cases where it is difficult for the compiler to break them, and > further requires that pointer variables carrying dependencies be marked. > (This proposal also includes prototype wording for the C++ standard, > a number of litmus tests, and some discussion.) Such marking might not > go down well with the Linux kernel community, which has been carrying > dependencies in unmarked variables for more than 15 years, so there is > further informal proposal asking C and C++ implementations to provide a > command-line option forcing the compiler to treat any pointer variable > as if it had been marked. (Why informal? Because command-line options > are outside of the scope of the standard.) > > There is a prototype implementation that obtains the functionality of > memory_order_consume without actually using memory_order_consume, which > is briefly described in a recent C++ working paper [3]. However, the > committee was not all that happy with this approach, preferring marking > of a single pointer variable to maintaining a separate variable to carry > the dependency. > > It would therefore be quite desirable to have an implementation that > allowed pointers to be marked as carrying dependencies, that avoided > the specified dependency-breaking optimizations on such pointers, and > that provided a command-line switch that caused the compiler to treat > all pointers as if they were to marked [2]. > > > [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html > [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf > [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html > > --- > > Ramana > End of forwarded message
Re: GCC 8.3 Status Report (2019-02-08)
On Fri, Feb 8, 2019 at 6:50 AM Nathan Sidwell wrote: > > On 2/8/19 3:15 AM, Jakub Jelinek wrote: > > Status > > == > > > > GCC 7.3 has been released on January 25th, so it is about time to do > > GCC 8.3 release now. Unfortunately we have a recent P1 C++ regression > > - PR88995. Nathan (or Jason), do you think it can be fixed soon? I think it was fixed by the patch for 88761 I just checked in. Jason > b) perhaps we shouldn't be sending non-dependent expressions through the > capture machinery, but instead wrapping them in an appropriate > view_convert_expr to make them const? > > > nathan > > -- > Nathan Sidwell
Re: [PATCH] Deprecate -frepo option.
On Thu, Jun 27, 2019 at 10:23 AM Martin Liška wrote: > > On 6/27/19 2:58 PM, Jonathan Wakely wrote: > > On Thu, 27 Jun 2019 at 13:30, Martin Liška wrote: > >> > >> On 6/21/19 4:28 PM, Richard Biener wrote: > >>> On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote: > > On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote: > > On 6/21/19 1:58 PM, Jakub Jelinek wrote: > >> On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote: > >>> On 6/21/19 1:47 PM, Jonathan Wakely wrote: > On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote: > > Yes, I would be fine to deprecate that for GCC 10.1 > > Would it be appropriate to issue a warning in GCC 10.x if the option > is used? > >>> > >>> Sure. With the patch attached one will see: > >>> > >>> $ gcc -frepo /tmp/main.cc -c > >>> gcc: warning: switch ‘-frepo’ is no longer supported > >>> > >>> I'm sending patch that also removes -frepo tests from test-suite. > >>> I've been testing the patch. > >> > >> IMHO for just deprecation of an option you don't want to remove it > >> from the > >> testsuite, just match the warning it will generate in those tests, and > >> I'm not convinced you want to remove it from the documentation (rather > >> than > >> just saying in the documentation that the option is deprecated and > >> might be > >> removed in a later GCC version). > > > > Agree with you. I'm sending updated version of the patch. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > I'm also not convinced about the Deprecated flag, seems like that is a > flag > that we use for options that have been already removed. > So, instead there should be some proper warning in the C++ FE for it, > or just Warn. > >>> > >>> In principle -frepo is a nice idea - does it live up to its promises? > >>> That is, > >>> does it actually work, for example when throwing it on the libstdc++ > >>> testsuite or a larger C++ project? > >> > >> @Jonathan, Jason: Do we know whether it really work? > > > > I don't know. It's nearly 20 years since I've tried it, but apparently > > a few people try using it: > > https://stackoverflow.com/search?q=frepo+c%2B%2B > > > > The first result was answered by me in 2012 saying nobody uses it: > > https://stackoverflow.com/a/11832613/981959 > > Looks at this, it seems to me very legacy and I would recommend to remove it. It's useful on targets without COMDAT support. Are there any such that we care about at this point? If the problem is the combination with LTO, why not just prohibit that? Jason
Re: Doubts regarding the _Dependent_ptr keyword
On Mon, Jul 1, 2019 at 8:59 PM 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 up to 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?
The usual way to check the output of an optimization pass is by
dumping the intermediate code at that point and matching the dump
against a regexp, as in the tree-ssa directories in the testsuite.
-fdump-tree-all will dump after all the gimple optimization passes,
and you can look through them until you find the breakage.
Jason
Re: [PATCH] Deprecate -frepo option.
On 7/9/19 1:48 PM, Nathan Sidwell wrote: On 7/9/19 9:00 AM, Martin Liška wrote: On 7/9/19 1:41 PM, Nathan Sidwell wrote: On 7/9/19 6:39 AM, Richard Biener wrote: On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and apparently 17 is not enough to resolve all symbols. And it's really slow. Ouch. hm, 17 is a magic number. in C++98 it was the maximum depth of template instantiations that implementations needed to support. Portable code could not expect more. So the worst case -frepo behaviour would be 17 iterations. That's not true any more, it's been 1024 since C++11. Has a bug been filed about this frepo problem? I create a new one: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91125 If not, it suggest those using frepo are not compiling modern C++. That said, I would recommend to remove it :) In the end it's up to the C++ FE maintainers but the above clearly doesn't look promising (not sure if it keeps re-compiling _all_ repo-triggered templates or just incrementally adds them to new object files). I'm not opposed to removing -frepo from GCC 10 but then I would start noting it is obsolete on the GCC 9 branch at least. I concur. frepo's serial reinvocation of the compiler is not compatible with modern C++ code bases. Great. Then I'm sending patch that does the functionality removal. Ready to be installed after proper testing & bootstrap? I'd like Jason to render an opinion, and we should mark it obsolete in the gcc 9 branch (how much runway would that give people?) I haven't noticed any responses to my earlier question: Are there any targets without COMDAT support that we still care about? But given the observation above about the 17 limit, even if there are such targets it wouldn't be very useful for modern code. And if people want to compile old code for old platforms, they might as well continue to use an old compiler. So I'm OK with deprecating with a warning for the next GCC 9 release, to see if anyone complains, and removing in 10. Jason
Re: [PATCH] Deprecate -frepo on gcc-9 branch (PR c++/91125).
On 7/11/19 3:02 AM, Jakub Jelinek wrote: On Thu, Jul 11, 2019 at 08:48:52AM +0200, Martin Liška wrote: --- a/gcc/c-family/c-opts.c +++ b/gcc/c-family/c-opts.c @@ -501,6 +501,8 @@ c_common_handle_option (size_t scode, const char *arg, HOST_WIDE_INT value, flag_use_repository = value; if (value) flag_implicit_templates = 0; + warning (0, "%<-frepo%> is deprecated and will be removed " + "in a future release"); break; Is there a reason not to condition this on OPT_Wdeprecated (which defaults to on)? Jason
Re: [PATCH] Deprecate -frepo on gcc-9 branch (PR c++/91125).
On 7/12/19 8:44 AM, Martin Liška wrote: On 7/11/19 7:25 PM, Jason Merrill wrote: On 7/11/19 3:02 AM, Jakub Jelinek wrote: On Thu, Jul 11, 2019 at 08:48:52AM +0200, Martin Liška wrote: --- a/gcc/c-family/c-opts.c +++ b/gcc/c-family/c-opts.c @@ -501,6 +501,8 @@ c_common_handle_option (size_t scode, const char *arg, HOST_WIDE_INT value, flag_use_repository = value; if (value) flag_implicit_templates = 0; + warning (0, "%<-frepo%> is deprecated and will be removed " + "in a future release"); break; Is there a reason not to condition this on OPT_Wdeprecated (which defaults to on)? Works for me. I'm sending updated version of the patch. Ready for gcc9 branch? LGTM. Jason
Re: GIMPLE clobber statement
The clobber means that 'a' no longer has a value, presumably because it has
gone out of scope.
On Tue, Jul 16, 2019, 2:07 PM navya deepika Garakapati <
navyadeepika.garakap...@gmail.com> wrote:
> Hi everyone,
>
> We are investigating the optimization issue with GCC trunk code and we have
> the below gimple code like
>
> a = 1;
> __asm__ __volatile__("");
> _9 = &a;
> a ={v} {CLOBBER};
> _4 = _9;
> _1 = *_4;
> std::basic_ostream::operator<< (&cout, _1);
>
>
> in the above gimple statements ,we would like to know the semantics of "a
> ={v} {CLOBBER}" and how this is interpreted by optimization ?
>
>
>
> Thank you
> Navya.
>
Re: LTO+profiled enabled builds
How does this do for you? On Thu, Jul 4, 2019 at 7:15 AM Matthias Klose wrote: > > I'm running into some issues building LTO+profiled enabled configurations in > some constrained build environment called buildds, having four cores and 16GB > of > RAM. > > configured for all frontends (maximum number of LTO links) and configured with > > --enable-bootstrap \ > --with-build-config=bootstrap-lto-lean \ > --enable-link-mutex > > and building the make profiledbootstrap-lean target. > > Most builds time out after 150 minutes. > > A typical LTO link runs for around one minute on this hardware, however a LTO > link with -fprofile-use runs for up to three hours. > > So gcc/lock-and-run.sh runs the first lto-link, waits for all other 300 > seconds, > then removes the "stale" locks, and runs everything in parallel ... Which > surprisingly goes well, because -flto=jobserver is in effect, so I don't see > any > memory constraints yet. > > The machine then starts building all front-ends, but apparently is not > overloaded, as -flto=jobserver is in effect. However there is no output, and > that triggers the timeout. Richi mentioned on IRC that the LTO links only have > buffered output (unless you run in debug mode), and that is only emitted once > the link finishes. However even with unbuffered output, there could be times > when nothing is happening, no warnings? > > I'm currently experimenting with a modified lock-and-run.sh, which basically > sets the delay for releasing the "stale" locks to 30min instead of 5 min, runs > the LTO link in the background and checks for the status of the background > job, > emitting some "running ..." messages while not finished. Still adjusting some > parameters, but at least that succeeds on some of my configurations. > > The locking mechanism was introduced in 2013, > https://gcc.gnu.org/ml/gcc-patches/2013-05/msg1.html > > lock-and-run.sh should probably modified not to release the "stale" locks > based > on a fixed timeout value. How? > > While the "no-output" problem can be fixed in the lock script as well > (attached), this doesn't apply to third party apps. Having unbuffered output > and/or an option to print progress would be beneficial. > > Matthias > > > commit c570f3f4751385153292c85c2f38dc78e9443923 Author: Jason Merrill Date: Sat Sep 14 14:02:20 2019 -0400 * lock-and-run.sh: Check for process existence rather than timeout. diff --git a/gcc/lock-and-run.sh b/gcc/lock-and-run.sh index 3a6a84c253a..b1a4a4c8220 100644 --- a/gcc/lock-and-run.sh +++ b/gcc/lock-and-run.sh @@ -5,29 +5,28 @@ lockdir="$1" prog="$2"; shift 2 || exit 1 # Remember when we started trying to acquire the lock. count=0 -touch lock-stamp.$$ -trap 'rm -r "$lockdir" lock-stamp.$$' 0 +trap 'rm -rf "$lockdir"' 0 until mkdir "$lockdir" 2>/dev/null; do # Say something periodically so the user knows what's up. if [ `expr $count % 30` = 0 ]; then - # Reset if the lock has been renewed. - if [ -n "`find \"$lockdir\" -newer lock-stamp.$$`" ]; then - touch lock-stamp.$$ - count=1 - # Steal the lock after 5 minutes. - elif [ $count = 300 ]; then - echo removing stale $lockdir >&2 - rm -r "$lockdir" + # Check for stale lock. + pid="`(cd $lockdir; echo *)`" + if ps "$pid" >/dev/null; then + echo waiting $count sec to acquire $lockdir from PID $pid>&2 + found=$pid else - echo waiting to acquire $lockdir >&2 + echo PID $pid is dead, removing stale $lockdir >&2 + rm -r "$lockdir" fi fi sleep 1 count=`expr $count + 1` done +touch $lockdir/$$ +echo acquired $lockdir after $count seconds >&2 echo $prog "$@" $prog "$@"
GCC Git hooks
At Cauldron this weekend Joel offered to adjust his git hooks
(https://github.com/brobecke/git-hooks), which are already used by gdb
and glibc, to meet GCC's needs. Separately, Joseph volunteered to
deal with converting the gcc-www repository to git and dealing with
those hooks.
I expect that Joel's hooks should work fine for gcc-www with minimal
changes, but that the main GCC repository will need more work for
bugzilla integration.
The GCC SVN hooks initially look like pretty vanilla SVN hooks using
svnmailer (http://opensource.perlig.de/svnmailer/); the customized
part of the svnmailer.conf is just
[libstdcxx]
for_paths = .*(libstdc..-v3)/.*
to_addr = libstdc++-...@gcc.gnu.org
[java]
for_paths = .*(boehm-gc|fastjar|gcjx|gcc/java|libffi|libjava|zlib)/.*
to_addr = java-...@gcc.gnu.org
[gccdefault]
to_addr = gcc-...@gcc.gnu.org
bugzilla_to_addr = gcc-bugzi...@gcc.gnu.org
Pretty short...but the last line relies on Daniel's custom
bugzilla/svnmailer integration (attached below), and it looks like
Joel's hooks don't have anything comparable. Any thoughts about
adjusting Daniel's bugzilla.py vs. pulling in something like
http://www.theoldmonk.net/gitzilla/ ?
Jason
# -*- coding: utf-8 -*-
#
# Copyright 2004-2006 André Malo or his licensors, as applicable
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
"""
Bugzilla based email notifiers (either piped to a program or via SMTP)
"""
__author__= "Daniel Berlin"
__docformat__ = "epytext en"
__all__ = ['getNotifier']
handled_bugs = {}
def getNotifier(config, groupset):
""" Returns an initialized notifier or nothing
@param config: The svnmailer config
@type config: C{svnmailer.settings.Settings}
@param groupset: The groupset to process
@type groupset: C{list}
@return: The list of notifiers (containing 0 or 1 member)
@rtype: C{list}
"""
from svnmailer import settings
from svnmailer.notifier import _textmail, _multimail
cls = None
if config.general.sendmail_command:
cls = SendmailSubmitter
elif config.general.smtp_host:
cls = SMTPSubmitter
if cls:
mtype = (groupset.groups[0].mail_type or u'single').split()[0].lower()
is_commit = (config.runtime.mode == settings.modes.commit)
mod = (is_commit and mtype == u'multipart') and \
_multimail or _textmail
return mod.getNotifier(cls, config, groupset)
return []
class SMTPSubmitter(object):
""" Use SMTP to submit the mail """
_settings = None
def sendMail(self, sender, to_addr, mail):
""" Sends the mail via SMTP """
import smtplib, cStringIO
fp = cStringIO.StringIO()
mail.dump(fp)
mail = fp.getvalue()
fp.close()
general = self._settings.general
conn = smtplib.SMTP(general.smtp_host)
if general.smtp_user:
conn.login(general.smtp_user, general.smtp_pass)
conn.sendmail(sender, to_addr, mail)
conn.quit()
class SendmailSubmitter(object):
""" Pipe all stuff to a mailer """
_settings = None
def sendMail(self, sender, to_addr, mail):
""" Sends the mail via a piped mailer """
global handled_bugs
from svnmailer import util
import sys
import re
import cStringIO
bugre = re.compile('\s+(?:bug|PR|BZ)\s+\#?\s*(?:[a-z\-\+]+\/)?(?:\/)?(\d+)(.*)$',re.I | re.S | re.M)
start = 0
fp = cStringIO.StringIO()
mail.dump(fp)
mailtxt = fp.getvalue()
fp.close()
result = bugre.search(mailtxt, start)
while result:
try:
bugnum = result.group(1)
if handled_bugs.has_key(bugnum) == False:
for group in [group for group in self._groupset.groups if group.bugzilla_to_addr]:
handled_bugs[bugnum] = True
mail.replace_header('To', group.bugzilla_to_addr)
mail.replace_header('Subject',"[Bug %s]" % (bugnum, ))
pipe = util.getPipe2(self._getMailCommand(sender, [group.bugzilla_to_addr]))
pipe.fromchild.close() # we don't expect something
mail.dump(pipe.tochild)
pipe.tochild.close()
# what do we do with the return code?
pipe.wait()
start = result.span(1)[1]
result = bugre.search(mailtxt, start)
except:
result = None
break
def _getM
Re: Adding -Wshadow=local to gcc build rules
On Fri, Sep 20, 2019, 2:21 PM Bernd Edlinger
wrote:
> On 9/19/19 12:19 PM, Richard Biener wrote:
> > On Wed, Sep 18, 2019 at 3:09 PM Bernd Edlinger
> > wrote:
> >>
> >> Hi,
> >>
> >> I'm currently trying to add -Wshadow=local to the gcc build rules.
> >> I started with -Wshadow, but gave up that idea immediately.
> >>
> >> As you could expect the current code base has plenty of shadowed
> >> local variables. Most are trivial to resolve, some are less trivial.
> >> I am not finished yet, but it is clear that it will be a rather big
> >> patch.
> >>
> >> I would like to ask you if you agree that would be a desirable step,
> >> in improving code quality in the gcc tree.
> >
> > I wonder if -Wshadow=compatible-local is easier to achieve?
> >
>
> I tried that and it does not make a big difference, while
> it misses for instance:
>
> * gcc/c-family/c-ada-spec.c (dump_ada_macros)
> unsigned char *s, shadowed by const unsigned char *s. :-/
>
> On the other hand, -Wshadow=global is a lot more difficult,
> because we have lots of globals, for instance:
>
> context.h:
> /* The global singleton context aka "g".
>(the name is chosen to be easy to type in a debugger). */
> extern gcc::context *g;
>
> But unfortunately Wshadow=local does not find class members
> shadowed by local variable, which happens for instance in
> wide-int
>
> With -Wshadow, I had to change this in wide-int.h:
>
> Index: gcc/wide-int.h
> ===
> --- gcc/wide-int.h (revision 275545)
> +++ gcc/wide-int.h (working copy)
> @@ -648,9 +648,9 @@ namespace wi
> storage_ref () {}
> storage_ref (const HOST_WIDE_INT *, unsigned int, unsigned int);
>
> -const HOST_WIDE_INT *val;
> -unsigned int len;
> -unsigned int precision;
> +const HOST_WIDE_INT *m_val;
> +unsigned int m_len;
> +unsigned int m_precision;
>
>
> So this change was not necessary for -Wshadow=local, although
> I would think that, shadowing class members is not much different from
> shadowing a local scope.
>
> Not sure if shadowing class members should be part of -Wshadow=local
> instead of -Wshadow=global.
>
That would make sense to me.
>
Re: taking OpenCL C as a built-in lang of GCC?
On Fri, Sep 20, 2019, 1:10 PM Jeff Law wrote: > On 9/12/19 8:48 AM, Jianbin Fang wrote: > > Hello Guys, > > > > > > > > I am working on OpenCL for a couple of years, and would like to ask, > > as for GCC, why not taking OpenCL C as a built-in language in its > > front-end? > There's no inherent reason why we don't support OpenCL C. Someone would > just need to write a suitable front-end for GCC and contribute it. > Or a patch to add it to the C front end. >
Re: Atomics in C++11
On Fri, Sep 20, 2019 at 8:32 AM Nicholas Krause wrote: > I was wondering if its possible to use the C11 atomics library for > multithreading > > GCC. Not sure if its a good idea due to concerns about older plaforms > not having a C11 supported libraries or compiler. I've been wondering if it's time to move to C++11 in general, since we've had compilers with C++11 support for more than 5 years at this point. Jason
Re: LTO+profiled enabled builds
Have you had a chance to try this? On Sat, Sep 14, 2019 at 2:39 PM Jason Merrill wrote: > > How does this do for you? > > On Thu, Jul 4, 2019 at 7:15 AM Matthias Klose wrote: > > > > I'm running into some issues building LTO+profiled enabled configurations in > > some constrained build environment called buildds, having four cores and > > 16GB of > > RAM. > > > > configured for all frontends (maximum number of LTO links) and configured > > with > > > > --enable-bootstrap \ > > --with-build-config=bootstrap-lto-lean \ > > --enable-link-mutex > > > > and building the make profiledbootstrap-lean target. > > > > Most builds time out after 150 minutes. > > > > A typical LTO link runs for around one minute on this hardware, however a > > LTO > > link with -fprofile-use runs for up to three hours. > > > > So gcc/lock-and-run.sh runs the first lto-link, waits for all other 300 > > seconds, > > then removes the "stale" locks, and runs everything in parallel ... Which > > surprisingly goes well, because -flto=jobserver is in effect, so I don't > > see any > > memory constraints yet. > > > > The machine then starts building all front-ends, but apparently is not > > overloaded, as -flto=jobserver is in effect. However there is no output, > > and > > that triggers the timeout. Richi mentioned on IRC that the LTO links only > > have > > buffered output (unless you run in debug mode), and that is only emitted > > once > > the link finishes. However even with unbuffered output, there could be > > times > > when nothing is happening, no warnings? > > > > I'm currently experimenting with a modified lock-and-run.sh, which basically > > sets the delay for releasing the "stale" locks to 30min instead of 5 min, > > runs > > the LTO link in the background and checks for the status of the background > > job, > > emitting some "running ..." messages while not finished. Still adjusting > > some > > parameters, but at least that succeeds on some of my configurations. > > > > The locking mechanism was introduced in 2013, > > https://gcc.gnu.org/ml/gcc-patches/2013-05/msg1.html > > > > lock-and-run.sh should probably modified not to release the "stale" locks > > based > > on a fixed timeout value. How? > > > > While the "no-output" problem can be fixed in the lock script as well > > (attached), this doesn't apply to third party apps. Having unbuffered > > output > > and/or an option to print progress would be beneficial. > > > > Matthias > > > > > >
Re: git conversion of GCC wwwdocs repository
On Tue, Sep 24, 2019 at 6:16 PM Joseph Myers wrote: > On Tue, 24 Sep 2019, Jonathan Wakely wrote: > > On Tue, 24 Sep 2019 at 21:46, Joseph Myers wrote: > > > > > > Would anyone like to make any comments on this conversion from CVS to git? > > > > It looks pretty good. I note that the author map just uses the > > committer's current email address, meaning I have commits using my > > @redhat.com address nearly a decade before I started working at Red > > Hat. But that's a small price to pay for moving from CVS to Git in my > > opinion. And t's arguably correct to have all my commits under one > > identity rather than several different ones anyway. > > If people prefer to use @gcc.gnu.org addresses, that's a small matter of > adjusting the postprocessing of the author map from the gcc-conversion > repository to replace the addresses there with usern...@gcc.gnu.org while > keeping the names from that author map. (The postprocessing is needed > anyway for this conversion because cvs-fast-export uses a more restricted > author map syntax than reposurgeon does. Because there is no ChangeLog in > wwwdocs, more sophisticated systems for identifying the relevant email > address for each commit from the ChangeLog aren't practical the same way > they are for the main GCC repository.) That would be my preference. Jason
Re: Moving to C++11
On Thu, Sep 26, 2019 at 4:08 AM Richard Biener wrote: > On Thu, Sep 26, 2019 at 9:23 AM Jonathan Wakely wrote: > > On Thu, 26 Sep 2019, 05:10 Nicholas Krause, wrote: > > > > > > Greetings, > > > > > > I asked about moving to C/C++ 11 as it would make it easier to > > > > > > allow multithreading support due to having a memory model > > > > > > alongside other features. Jason Merill mentioned due to it > > > > > > being so common it may be a good time to. > > > > > > Moving to git seems to be universally agree on so I'm opening the > > > discussion > > > > > > for the same as related to C/C++11 migration and if possible opening > > > > > > a TODO similar to git if decided on. > > > > > > Please post your comments or ideas about the migration in response to this > > > > > > email, > > > > > > > > For a start, it doesn't make sense to talk about C/C++11. > > > > C and C++ are separate languages, and so are C11 and C++11. There is > > no reason why using C++11 should imply using C11, let's not confuse > > things. > > > > GCC is written in C++ so the topic should be C++11. > > Note the main issue is host compiler support. I'm not sure if C++11 would > be the step we'd gain most - for some hashtable issues I'd have needed > std::move support for example. There's always the possibility to > require an intermediate step (first build GCC 5, with that you can build > trunk, etc.), a install.texi clarification could be useful here (or even > some automation via a contrib/ script). Note that std::move is from C++11. > I'm not too worried about requiring even a C++14 compiler, for the > set of products we still release latest compilers we have newer > GCCs available we can use for building them (even if those are > not our primary supported compilers which would limit us to > GCC 4.8). I wouldn't object to C++14, but there's nothing in there I particularly want to use, so it seems unnecessary. > Note I'd still not like to see more C++ feature creep into general > non-container/infrastructure code, C++ is complex enough as-is. I agree for rvalue references. I want to start using C++11 'auto' in local variable declarations. Jason
Re: Commit messages and the move to git
On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely wrote: > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote: > > On Mon, 4 Nov 2019, Segher Boessenkool wrote: > > > > > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote: > > > > I've already proposed a more specific format for libstdc++: > > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html > > > > > > PR libstdc++/12345 takes up the first 19 chars of the short subject, > > > adding no useful information (unless the reader knows all PRs by heart, > > > you need to look it up to know what it is). > > > > > > I usually put (PR12345) at the end of the subject. The area is clear > > > from the rest of the subject already. > > > > Agreed. (Hint to patch submitters: if the subject line of your patch > > submission is just "Fix PR12345" or similar, people are less likely to > > review your patch because nothing about the subject tells anyone that the > > patch is in their area and so something they should pay attention to. > > Patch submissions need to have subjects that make clear very quickly what > > the patch is about. This is also why I don't care for [PATCH] tags at the > > start of subject lines - they take away space for saying what the patch is > > about, and on gcc-patches we can expect things are patches, [PATCH] > > doesn't add useful information.) > > I don't mind [PATCH] in the subject of patch emails (maybe because > nearly all my patches go to libstdc++@ as well, and not all mails on > that list are patches), but it has negative value in the commit log. I actively like [PATCH] in the subject line because I see patch mail interleaved with other mail in my inbox. > My mail to the libstdc++ list should have noted that [PATCH] tags in > the email subject should be omitted from the summary in the first line > of the commit log. And git format-patch/git am automatically add and remove [PATCH] appropriately. I tend to put the PR number at the beginning of the line, but I don't object to putting it at the end instead. Jason
Re: Feedback request on how best to handle recursion in concept satisfaction
On Tue, Nov 5, 2019 at 2:42 PM Jeff Chapman wrote:
>
> On Thu, Oct 31, 2019 at 8:03 AM Nathan Sidwell wrote:
> > Why doesn't the std specify the satisfaction nesting limit in the same
> > way as template instantiation? (at least that's what I infer from your
> > question).
>
> I'm not sure why it's not explicitly listed along with the template
> instantiation limit ([implimits]/2.41). Perhaps it's something that
> should be added? It does seem like a distinct limit since satisfaction
> can occur recursively without having more than one template
> instantiation in the call stack at any given time. To give an example:
>
> template
> requires requires(T t) { foo(t); }
> void foo(T t) { }
>
> A call to foo<1>(1) results in unbounded call stack like:
>
> resolve foo<1>(int)
> instantiate the decl of foo<1>(int)
> check if foo<1>(int) satisfies its constraints
> resolve foo<2>(int)
> instantiate the decl of foo<2>(int)
> check if foo<2>(int) satisfies its constraints
> ...
>
> Per [temp.inst]/17 "the type-constraints and requires-clause of a
> template specialization or member function are not instantiated along
> with the specialization or function itself" so instantiating the decl
> of foo<1>(int) does not depend on the instantiation of any other
> template and the template instantiation depth is only incremented once
> before decremented when control flow returns to overload resolution.
>
> This needs to be resolved someway, but reusing the template
> instantiation depth limit would be an odd choice since there are no
> recursive template instantiations in the process. A parallel
> -fsatisfaction-depth= limit and associated diagnostics seems like a
> better way to resolve this issue.
We track other substitution cases as part of the template
instantiation depth limit, notably instantiating the
noexcept-specifier. This seems like a similar situation.
Jason
Re: Commit messages and the move to git
On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > On Mon, Nov 18, 2019 at 07:21:22PM +, Richard Earnshaw (lists) wrote: > > On 18/11/2019 18:53, Segher Boessenkool wrote: > > > PR target/92140: clang vs gcc optimizing with adc/sbb > > > PR fortran/91926: assumed rank optional > > > PR tree-optimization/91532: [SVE] Redundant predicated store in > gcc.target/aarch64/fmla_2.c > > > PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at > tree-vect-stmts.c:1687 > > > PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction, > at tree-vect-loop.c:4252 > > > PR c++/92015: internal compiler error: in cxx_eval_array_reference, at > cp/constexpr.c:2568 > > > PR tree-optimization/92173: ICE in optab_for_tree_code, at > optabs-tree.c:81 > > > PR tree-optimization/92173: ICE in optab_for_tree_code, at > optabs-tree.c:81 > > > PR fortran/92174: runtime error: index 15 out of bounds for type > 'gfc_expr *[15] > > > > > > Most of these aren't helpful at all, and none of these are good commit > > > summaries. The PR92173 one actually has identical commit messages btw, > > > huh. Ah, the second one (r277288) has the wrong changelog, but in the > > > actual changelog file as well, not something any tool could fix up (or > > > have we reached the singularity?) > > > > Identical commits are normally from where the same commit is made to > > multiple branches. It's not uncommon to see this when bugs are fixed. > > This is an actual mistake. The commits are not identical at all, just > the commit messages are (and the changelog entries, too). Not something > that happens to ften, but of course I hit it in the first random thing I > pick :-) > > > Ultimately the question here is whether something like the above is more > > or less useful than what we have today, which is summary lines of the > form: > > > > > > I already said I would prefer things like > Patch related to PR323 > as the patch subject lines. No one argues that the current state of > affairs is good. I argue that replacing this with often wrong and > irrelevant information isn't the best we can do. > How about using the first line that isn't a ChangeLog date/author line, without trying to rewrite/augment it? Jason
Re: Commit messages and the move to git
On Mon, Nov 18, 2019 at 4:38 PM Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > On 18/11/2019 20:53, Jason Merrill wrote: > > On Mon, Nov 18, 2019 at 2:51 PM Segher Boessenkool < > > seg...@kernel.crashing.org> wrote: > > > >> On Mon, Nov 18, 2019 at 07:21:22PM +, Richard Earnshaw (lists) > wrote: > >>> On 18/11/2019 18:53, Segher Boessenkool wrote: > >>>> PR target/92140: clang vs gcc optimizing with adc/sbb > >>>> PR fortran/91926: assumed rank optional > >>>> PR tree-optimization/91532: [SVE] Redundant predicated store in > >> gcc.target/aarch64/fmla_2.c > >>>> PR tree-optimization/92161: ICE in vect_get_vec_def_for_stmt_copy, at > >> tree-vect-stmts.c:1687 > >>>> PR tree-optimization/92162: ICE in vect_create_epilog_for_reduction, > >> at tree-vect-loop.c:4252 > >>>> PR c++/92015: internal compiler error: in cxx_eval_array_reference, at > >> cp/constexpr.c:2568 > >>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at > >> optabs-tree.c:81 > >>>> PR tree-optimization/92173: ICE in optab_for_tree_code, at > >> optabs-tree.c:81 > >>>> PR fortran/92174: runtime error: index 15 out of bounds for type > >> 'gfc_expr *[15] > >>>> > >>>> Most of these aren't helpful at all, and none of these are good commit > >>>> summaries. The PR92173 one actually has identical commit messages > btw, > >>>> huh. Ah, the second one (r277288) has the wrong changelog, but in the > >>>> actual changelog file as well, not something any tool could fix up (or > >>>> have we reached the singularity?) > >>> > >>> Identical commits are normally from where the same commit is made to > >>> multiple branches. It's not uncommon to see this when bugs are fixed. > >> > >> This is an actual mistake. The commits are not identical at all, just > >> the commit messages are (and the changelog entries, too). Not something > >> that happens to ften, but of course I hit it in the first random thing I > >> pick :-) > >> > >>> Ultimately the question here is whether something like the above is > more > >>> or less useful than what we have today, which is summary lines of the > >> form: > >>> > >>> > >> > >> I already said I would prefer things like > >> Patch related to PR323 > >> as the patch subject lines. No one argues that the current state of > >> affairs is good. I argue that replacing this with often wrong and > >> irrelevant information isn't the best we can do. > >> > > > > How about using the first line that isn't a ChangeLog date/author line, > > without trying to rewrite/augment it? > > > > Jason > > > > It would certainly be another way of doing it. Sometimes it would > produce almost the same as an unadulterated PR; sometimes it would > produce something more meaningful and sometimes it would be pretty > useless. It probably would hit more cases than my current script in > that it wouldn't require the commit to mention a PR in it. > > The main problem is that the first line is often incomplete, and much of > it is also wasted with elements like the full path to a file that is > quite deep in the tree. Lets take a quick example (the first I found in > the dump I have). > > 1998-12-17 Vladimir N. Makarov > * config/i60/i960.md (extendqihi2): Fix typo (usage ',' instead of > ';'). > 1998-12-17 Michael Tiemann > * i960.md (extend*, zero_extend*): Don't generate rtl that looks > like (subreg:SI (reg:SI N) 0), because it's wrong, and it hides > optimizations from the combiner. > > Firstly, this example misses a blank line between the author and the > change message itself, which makes distinguishing between this and the > multiple authors case harder. Secondly, the entry really spans two > lines and cutting it off at the end of the first line would be, well a > bit odd. We could try to piece things together more, by combining lines > until we find a sentence end ( \.$ or \.\s\s ), and we could also strip > off more of the path components to just leave the name of the file > committed. For example, > > i960.md (extendqihi2): Fix typo (usage ',' instead of ';'). > > That might work better, but obviously it's harder to handle and thus > more likely to create erroneous summaries. > Yep. I don't think we need to worry about getting optimal one-line summaries for ancient commits; something reasonably unique should be plenty.
Re: Commit messages and the move to git
On Tue, Nov 19, 2019 at 11:31 AM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote: > > Yep. I don't think we need to worry about getting optimal one-line > > summaries for ancient commits; something reasonably unique should be > plenty. > > In that case, how about just "SVN rNN"? And then we don't need the > footer from git-svn anymore either? And don't need to mangle or wrangle > the commit message itself at all either. > Well, I was thinking of also giving some clue of what the commit was about. One possibly cut-off line accomplishes that, a simple revision number not so much. Jason
Re: Commit messages and the move to git
On Wed, Nov 20, 2019 at 6:27 AM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > It would be good if whatever convention we do for commit messages and > their first line would be machine parseable as well. > The first line should be useful to humans, machines can parse the whole message. Jason
Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)
On Thu, Dec 5, 2019 at 11:51 AM Michael Matz wrote: > Hello, > > (oh a flame bait :) ) > > On Thu, 5 Dec 2019, Thomas Schwinge wrote: > > > So, I formally propose that we lift this characters per line restriction > > from IBM punch card (80) to mainframe line printer (132). > > > > Tasks: > > > > - Discussion. > > I object to cluttering code in excuse for using sensible function names or > temporaries that otherwise can help clearing up code. Using 132-char > lines is cluttering code: > - long lines are harder to read/grasp: vertical eye movement is easier > than horizontal, and source code should be optimized for > reading, not writing > - long lines make it impossible to have two files next to each other at a > comfortable font size > - long lines are incompatible with existing netiquette re emails, for > instance > > So, at least for me, that my terminals are 80 wide (but not x24) has > multiple reasons, and the _least_ of it is because that's what punch cards > had. > Agreed. I work with two side-by-side terminals, one 80x50 and the other as wide as fits in the rest of the screen, which currently happens to be 111x50. Jason
Re: [PATCH] Re: Minimal GCC version to compile the trunk
On 12/7/19 3:50 AM, Jakub Jelinek wrote:
On Fri, Dec 06, 2019 at 06:43:35PM -0800, Andrew Pinski wrote:
Hi all,
Right now the trunk does not compile with GCC 4.4.7 (the GCC that
comes with CentOS 6; yes I know old) after revision 277200 (October
19).
AFAIK we haven't switched to requiring C++11 at which point we'd need to
bump minimal system GCC requirement to 4.8-ish or so, so currently we
should support building with even GCC 4.1-ish.
The error message is:
../../gcc/gcc/cp/cvt.c:1043: error: operands to ?: have different
types ‘escaped_string’ and ‘const char [1]’
../../gcc/gcc/cp/cvt.c:1060: error: operands to ?: have different
types ‘escaped_string’ and ‘const char [1]’
Indeed. I think it is r151113 or r151114 that fixed that.
Is it acceptable to put in a workaround for this?
Yes. I'd suggest to also fix the formatting around (? and : at the end
of lines), so something like this?
I've tested the workaround back to GCC r8.
Note, not accepting the code as is clearly has been a regression in GCC 3.4
to 4.4, as GCC 3.2 or 3.3 happily accept that.
Ok for trunk if it passes bootstrap/regtest?
OK.
2019-12-07 Jakub Jelinek
* cvt.c (maybe_warn_nodiscard): Add workaround for GCC 3.4-4.4 - cast
msg to (const char *) in conditional expressions. Formatting fixes.
--- gcc/cp/cvt.c.jj 2019-12-04 10:26:36.0 +0100
+++ gcc/cp/cvt.c2019-12-07 09:39:58.145990796 +0100
@@ -1044,12 +1044,13 @@ maybe_warn_nodiscard (tree expr, impl_co
tree args = TREE_VALUE (attr);
if (args)
msg.escape (TREE_STRING_POINTER (TREE_VALUE (args)));
- const char* format = (msg ?
- G_("ignoring return value of %qD, "
- "declared with attribute %: %<%s%>") :
- G_("ignoring return value of %qD, "
- "declared with attribute %%s"));
- const char* raw_msg = msg ? msg : "";
+ const char *format
+ = (msg
+ ? G_("ignoring return value of %qD, "
+ "declared with attribute %: %<%s%>")
+ : G_("ignoring return value of %qD, "
+ "declared with attribute %%s"));
+ const char *raw_msg = msg ? (const char *) msg : "";
auto_diagnostic_group d;
if (warning_at (loc, OPT_Wunused_result, format, fn, raw_msg))
inform (DECL_SOURCE_LOCATION (fn), "declared here");
@@ -1061,12 +1062,13 @@ maybe_warn_nodiscard (tree expr, impl_co
tree args = TREE_VALUE (attr);
if (args)
msg.escape (TREE_STRING_POINTER (TREE_VALUE (args)));
- const char* format = msg ?
- G_("ignoring returned value of type %qT, "
- "declared with attribute %: %<%s%>") :
- G_("ignoring returned value of type %qT, "
- "declared with attribute %%s");
- const char* raw_msg = msg ? msg : "";
+ const char *format
+ = (msg
+ ? G_("ignoring returned value of type %qT, "
+ "declared with attribute %: %<%s%>")
+ : G_("ignoring returned value of type %qT, "
+ "declared with attribute %%s"));
+ const char *raw_msg = msg ? (const char *) msg : "";
auto_diagnostic_group d;
if (warning_at (loc, OPT_Wunused_result, format, rettype, raw_msg))
{
Jakub
