instrumentation injection & trees
I'm new to the gcc community. I've been asked to modify gcc to allow it to inject various kinds of instrumentation during compilation. My current plan is to capture the tree being generated by the front end, augment it, and pass it on to the back end. It seems like a reasonable approach but I can't find much information about interpreting and manipulating trees. Does anyone have any information about this technique of wedging code between the front and back ends, or, better yet, some examples? Is there a better approach? Are there existing tools that might eliminate the need to write this instrumentation injector from scratch?
Re: Proposed semantics for attributes in C++ (and in C?)
Mark Mitchell wrote: Yes, I would be happy to explicitly ignore semantic attributes in typedefs as well, with a warning (or even an error). However, I had not realized that we ever did that; I'm surprised that the change that instituted this is so recent. I suppose that explains why we're suddenly seeing a rash of such problems. Jason, as you made this change, do you have any comments on the proposal? I don't think my patch changed the handling of class typedefs; certainly my intent was only to change how we handle class __attribute ((foo)) C Previously we rejected it, now we apply the attributes to the class. Which PRs are you referring to? I'd be inclined to prohibit semantic attributes on typedefs in general. Extending the type system to handle attribute types seems excessively complicated. I think we should define a set of attributes which prevent us from taking the address of a variable with that attribute (packed...anything else?) and check for them at the same places we check for taking the address of a bitfield. Jason
Re: Proposed semantics for attributes in C++ (and in C?)
Joseph S. Myers wrote:
I was referring to the change in extend.texi
-the closing brace. It is ignored if the content of the structure, union
-or enumerated type is not defined in the specifier in which the
-attribute specifier list is used---that is, in usages such as
[EMAIL PROTECTED] __attribute__((foo)) bar} with no following opening brace.
+the closing brace. The former syntax is preferred.
That passage has nothing to do with typedefs. The change is that
previously, if we saw
class __attribute ((visibility (hidden))) C;
we would ignore the attribute, now we record it.
My change to the previous paragraph now seems excessive, however:
-You may specify the @code{aligned} and @code{transparent_union}
-attributes either in a @code{typedef} declaration or just past the
-closing curly brace of a complete enum, struct or union type
[EMAIL PROTECTED] and the @code{packed} attribute only past the closing
-brace of a definition.
+You may specify type attributes either in a @code{typedef} declaration
+or in an enum, struct or union type declaration or definition.
I didn't notice the distinction this passage was trying to make between
packed and other attributes, just that it was an incomplete list. In
removing the incomplete list I also removed the useful separation.
Jason
Jakub Jelinek as libgomp maintainer
The SC has appointed Jakub Jelinek as an additional maintainer of the GNU OpenMP library (libgomp). Jakub, please update MAINTAINERS accordingly. Thanks! Jason
reading binarys
I'm working on a project where every so often one of our games comes back and we pull the ram off the game for saving, and sometimes for anaylisis. Currently the only varibles in ram that we can physically look at are the static members. The information that we would love to get to is the heap memory and be able to know what dynamically allocated structure that heap memory belongs to. I have the source code, I have the binarys, I have the ram dumps, I have the boards. Our games have the ability to recover back to the original state that they were in before a power hit, so even though the memory is dynamically allocated, our code is the only running code on the machine and since it runs the code in the same order every time, the pointers get put into the same memory locations every time. What I need to know, is there some way to read the binary with some program to figure out which order everything in memory is being allocated, so that I can write a program to read the memory dump and figure out which memory locations belong to which pointer varibles. Our code is written in C with litteraly tons of pointers. It runs on the i960 processor (yeah I know...soo old...but it works and it costs a lot of money to change once its been approved). Any ideas would be appricated to be able to read the binary to figure out the order in which varibles get loaded onto the heap.
Re: reading binarys
I''l give that a shot. Thanks On 1/25/07, Mike Stump <[EMAIL PROTECTED]> wrote: On Jan 25, 2007, at 2:11 PM, Jason Erickson wrote: > I'm working on a project where every so often one of our games comes > back and we pull the ram off the game for saving, and sometimes for > anaylisis. Currently the only varibles in ram that we can physically > look at are the static members. The information that we would love to > get to is the heap memory and be able to know what dynamically > allocated structure that heap memory belongs to. Heap objects can be found by looking at stack and global variables. > What I need to know, is there some way to read the binary with some > program to figure out which order everything in memory is being > allocated, so that I can write a program to read the memory dump and > figure out which memory locations belong to which pointer varibles. > Our code is written in C with litteraly tons of pointers. It runs on > the i960 processor (yeah I know...soo old...but it works and it costs > a lot of money to change once its been approved). > > Any ideas would be appricated to be able to read the binary to figure > out the order in which varibles get loaded onto the heap. First, wrong list. gcc-help is closer, but that is for compiler help. Your question really has little to do with the compiler, but rather, debugging. You could create a gdb remote stub for your game and then just fire up gdb with the `core file'. Assumes that you've enhanced gdb to read your core files. You can save off the -g built game and point the debugger at that code. You then debug any data structures you want, using gdb. If you just want a memory map, see the ld documentation. If you're question is how do I write a debugger, please, don't do that, just reuse gdb. It supports remote debugging and i960s just fine. -- Jennys Website http://www.dontbflat.com
Re: reading binarys
Ok, well that didnt work. First off our game has too many safety protocols that prevent me from creating a stub and not clearing the memory, so that goes out the window. I actually found the structure I needed (luckly) by looking at the map file, howevernow I'm stuck going through the memory (outputed into HEX) and associating each portion in memory with a specific varible. Its a long and tedious process. Is there anything out there that I can give it a .h file and I can say "this structure starts here, output the full listing of my variables"? Or , is there anything that can take a .h file and output a nice easy to parse listing that can give me type, name, and structure it belongs too? I tried Etags/Ctags, but that doesnt give me type. Any other ideas? On 1/25/07, Jason Erickson <[EMAIL PROTECTED]> wrote: I''l give that a shot. Thanks On 1/25/07, Mike Stump <[EMAIL PROTECTED]> wrote: > On Jan 25, 2007, at 2:11 PM, Jason Erickson wrote: > > I'm working on a project where every so often one of our games comes > > back and we pull the ram off the game for saving, and sometimes for > > anaylisis. Currently the only varibles in ram that we can physically > > look at are the static members. The information that we would love to > > get to is the heap memory and be able to know what dynamically > > allocated structure that heap memory belongs to. > > Heap objects can be found by looking at stack and global variables. > > > What I need to know, is there some way to read the binary with some > > program to figure out which order everything in memory is being > > allocated, so that I can write a program to read the memory dump and > > figure out which memory locations belong to which pointer varibles. > > Our code is written in C with litteraly tons of pointers. It runs on > > the i960 processor (yeah I know...soo old...but it works and it costs > > a lot of money to change once its been approved). > > > > Any ideas would be appricated to be able to read the binary to figure > > out the order in which varibles get loaded onto the heap. > > First, wrong list. gcc-help is closer, but that is for compiler > help. Your question really has little to do with the compiler, but > rather, debugging. You could create a gdb remote stub for your game > and then just fire up gdb with the `core file'. Assumes that you've > enhanced gdb to read your core files. You can save off the -g built > game and point the debugger at that code. You then debug any data > structures you want, using gdb. If you just want a memory map, see > the ld documentation. > > If you're question is how do I write a debugger, please, don't do > that, just reuse gdb. It supports remote debugging and i960s just fine. > -- Jennys Website http://www.dontbflat.com -- Jennys Website http://www.dontbflat.com
Re: Import GCC 4.2.0 PRs
Mark Mitchell wrote: * PR 27945 (Merill) * PR 30590 (Guenther, Merill) I'll get on these. Jason
Re: GCC 4.2.0 Status Report (2007-03-22)
Diego Novillo wrote: I traced the problem back to the building of vtables. I'm simply calling cxx_mark_addressable after building the ADDR_EXPR (I'm wondering if building ADDR_EXPR shouldn't just call langhooks.mark_addressable). Looks fine to me. Many places in the front end use build_address rather than build1 (ADDR_EXPR) to avoid this issue. Jason
Re: GCC 4.2.0 Status Report (2007-03-22)
Diego Novillo wrote: Interestingly enough, mark_addressable refuses to mark the label as addressable, but we need the label addressable so that it's processed properly by the compute_may_aliases machinery. Given that we need to be very consistent about addressability marking in the FEs, wouldn't we be better off doing this in build1_stat()? + if (DECL_P (node)) + TREE_ADDRESSABLE (node) = 1; I'd rather fix mark_addressable and use the langhook. Jason
Re: Inclusion in an official release of a new throw-like qualifier
Sergio Giro wrote:
I started a thread about the possible development of a throw-like
qualifier for C++ which may statically check that the only possible
exceptions are those declared in the qualifier (please see the
corresponding thread:
I'm strongly opposed to adding a new qualifier with slightly different
semantics from one already in the language. I agree with Mike that the
right answer is to implement stricter checking of standard exception
specifications.
Furthermore, gcc internals currently don't support much in the way of
inter-procedural analysis, and none between routines in separate
modules. So if your function calls another function, we don't know what
it can throw (unless the called function also has an exception
specification). If you want more than single-function analysis, you're
probably better off with an external tool, at least for now.
Sergio Giro wrote (in reply to Mike Stump):
> is ideal, but it seems to me not practical at all. Every stuff using
> the throw qualifier as specified in the standards will not work. If an
> inline method in a standard header is
> theInlineMethod (void) throw () { throw theException(); };
> this will not even compile...
I doubt that anything like this appears in the standard headers.
> In addition, the semantic meaning is not the same: a
> throw (a,b,c) qualifier indicates that you are able only to catch the
> exceptions a, b and c, and that every other exception will be seen as
> std::unexpected. Nevertheless, a
> _throw(a,b,c) qualifier should indicate that the only exceptions that
> can arise are a, b and c.
But in both cases, the only exceptions that can leave the function are
a, b and c. I don't see what your extension would add that wouldn't
also be provided by -Wexception-specs.
Jason
Re: Inclusion in an official release of a new throw-like qualifier
Sergio Giro wrote: I perceived that many people think that the throw qualifiers, as described by the standard, are not useful Yes. But that's not a reason to add a slightly different non-standard feature that would require people already using standard exception specifications to rewrite everything. That's just a non-starter. You asked how likely your proposed extension is to be included in an official GCC release. My answer is, very unlikely. However, a flag to perform static checking of standard exception specifications and warn about violations is very likely to be included. Jason
Re: matching constraints in asm operands question
On Sat, 5 Mar 2005 00:24:10 -0500, [EMAIL PROTECTED] wrote:
>> static __inline__ void atomic_add(atomic_t *v, int i)
>> {
>> __asm__ __volatile__("addl %1,%0" : "+m" (*v) : "d" (i));
>> }
>>
>> Then the compiler complains with:
>>
>> /asm/atomic.h:33: warning: read-write constraint does not allow a register
>>
>> So is the warning wrong?
>
> Yes, the warning is wrong, and the text in the manual about '+' is also
> nonsense. Support for '+' is asms was specifically introduced to make
> it safe to have read-write memory operands. Jason, the point of using '+'
> is that the matched parts start out as the same, and the compiler is
> supposed to keep them the same.
Well, I assumed the same thing when I started poking at that code, but then
someone pointed out that it didn't actually work that way, and as I recall
the code does in fact assume a register. I certainly would not object to
making '+' work properly for memory operands, but simply asserting that it
already does is wrong.
Jason
Re: [Bug c++/19199] [3.3/3.4/4.0/4.1 Regression] Wrong warning about returning a reference to a temporary
On Mon, 07 Mar 2005 11:49:05 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote: > IMO, if these are C++-only, it's relatively easy to deprecate these > extension -- but I'd like to hear from Jason and Nathan, and also the user > community before we do that. Of all the extensions we've had, this one > really hasn't been that problematic. I agree it hasn't been problematic. I suspect that part of the reason for that is that it hasn't been used. I would not object to deprecating the syntax extension. Jason
bootstrap 4.0-200503005: flag_unsafe_math_optimizations undeclared
Using binutils 2.15.96 and gcc 3.4.3... where have I gone wrong? -Jason gcc -c -g -DENABLE_CHECKING -DENABLE_ASSERT_CHECKING -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE-I. -Ibuild -I../../gcc-4.0-20050305/gcc -I../../gcc-4.0-20050305/gcc/build -I../../gcc-4.0-20050305/gcc/../include -I../../gcc-4.0-20050305/gcc/../libcpp/include \ -o build/insn-conditions.o insn-conditions.c insn-conditions.c:97: error: `flag_unsafe_math_optimizations' undeclared here (not in a function) insn-conditions.c:97: error: initializer element is not constant insn-conditions.c:97: error: (near initialization for `insn_conditions[10].value') insn-conditions.c:97: warning: missing initializer insn-conditions.c:97: warning: (near initialization for `insn_conditions[10].value') insn-conditions.c:97: error: initializer element is not constant insn-conditions.c:97: error: (near initialization for `insn_conditions[10]') ...
RE: bootstrap 4.0-200503005: flag_unsafe_math_optimizations undeclared
insn-conditions.c:97: error: `flag_unsafe_math_optimizations' undeclared here Using binutils 2.15.96 and gcc 3.4.3... where have I gone wrong? Of course if I would have searched the archives first, I would know that I need a new gawk most likely. [argh] -Jason
Re: GCC 4.0 Status Report (2005-03-24)
On Thu, 24 Mar 2005 11:29:09 -0800, Mark Mitchell <[EMAIL PROTECTED]> wrote: > 19317 C++ problems with temporary return values > > This patch breaks Qt builds. One of my patches is implicated, but I > believe that the consensus is that this is an NRV bug. Jason made > several attempts at fixing this. Does anyone know what the current > status is? Basically, the problem is that the return slot optimization in expand_call is incompatible with the NRVO; if the callee shares the return slot with a variable, the caller can't share it with an object which escapes. expand_call has no way of checking whether "target" escapes, so I think we probably just need to disable the optimization there. I was trying to implement the optimization at the tree level by making the return slot argument explicit in the GIMPLE form, with CALL_EXPR_HAS_RETURN_SLOT. This caused problems with some code that didn't know to check that flag...which led me to think that if it requires a lot of special handling, perhaps the flag is the wrong way to make the return slot explicit. But I don't have a better idea atm. Jason
Re: GCC 4.0 Status Report (2005-04-05)
On Mon, 04 Apr 2005 16:26:23 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote: > There are three outstanding bugs (19317, 19312, 18604) assigned to Jason > Merrill, but I didn't hear back from him last week. Jason, I'm going to > assume that you're unable to work on these. As Nathan is on vacation, I > suppose that means that these will fall to me to fix. If anyone else would > like to volunteer for 19317, which has proven particularly thorny, that > would be helpful. There's a patch in the comments for 19317 that just disables the offending optimization. I'll try to deal with the other two tomorrow. Jason
Re: GCC 4.0 RC2
On Tue, 12 Apr 2005 10:59:42 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Sadly, it's become clear there's going to have to be a second release > candidate. In particular, there are some wrong-code bugs that are popping > up on real packages on primary platforms. Jason Merill is looking into > some of the C++ issues, but he's in Lillehammer this week for the ISO > meeting. Actually, I'm not. I don't think these are C++ front end bugs, though they are showing up with C++ packages. I'd take a look if there were a manageable testcase for me to look at, but I don't have time to learn my way around KDE and openoffice in order to find the bugs. I think other people are working on tracking these down, though. The relevant PRs seem to be 20949 and 20973; there's also some (off-topic) discussion in 19317. Jason
Heads-up: volatile and C++
The C++ committee (well, a subgroup represented at this meeting by Hans
Boehm) is working on a memory model that supports threaded programs. One
proposed change is to the semantics of volatile. Currently, volatile
semantics are constrained by:
6 The observable behavior of the abstract machine is its sequence of
reads and writes to volatile data and calls to library I/O
functions.6)
7 Accessing an object designated by a volatile lvalue (_basic.lval_),
modifying an object, calling a library I/O function, or calling a
function that does any of those operations are all side effects, which
are changes in the state of the execution environment. Evaluation of
an expression might produce side effects. At certain specified points
in the execution sequence called sequence points, all side effects of
previous evaluations shall be complete and no side effects of
subsequent evaluations shall have taken place.7)
My reading of this is that currently, a volatile read or write should act
as a barrier to other writes ("modifying an object"), because generally
there will be a sequence point between those writes and the volatile
access.
The proposal is that volatile reads act as an acquire (hoist barrier), and
volatile writes act as a release (sink barrier). These precisely
correspond to the ia-64 ld.acq and st.rel instructions; other architectures
may or may not need memory barrier instructions. Hans suggests that these
semantics are already required by the Itanium documentation.
The difference from this from what I percieve the current standard to say
is
1) volatile reads and writes now inhibit movement of loads in one direction
(and therefore constrain CSE).
2) movement of stores is allowed in one direction across volatile reads and
writes, where before it was fully blocked.
This all makes sense to me, but I'm interested in feedback.
Jason
Re: Heads-up: volatile and C++
On Thu, 14 Apr 2005 10:12:37 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote: > Jason Merrill wrote: >> The C++ committee (well, a subgroup represented at this meeting by Hans >> Boehm) is working on a memory model that supports threaded programs. > > As someone who uses the C++ language and multi-threading > extensively in embedded systems, I have come to the following > belief/opinion. > >The language (C++) *should not* have dependencies >upon threading. IMHO, threading is a layer above a >systems programming language, and having dependencies >upon upper layers is evil. But the memory model for the language must provide semantics that make it possible for threaded programs to be written. Currently, if you want to write a portable pthreads program you need to use a mutex around all uses of shared memory, because they are the only way to guarantee sequential memory ordering. The volatile proposal provides a lighter-weight way to write portable code with explicit memory ordering. You need this for lockless algorithms to work. > Since IANALL, but I believe (as obviously you do) > that changing the semantics of volatile should be > under-taken with great care. > > I'm not familiar with ia64 barrier instructions, but I > *am* familiar with PowerPC barrier and synchronization > instructions (eieio, sync, isync, etc.), and I would > question the practice of automatically generating > these as side effect of a variable being declared > as volatile, if for no other reason than the possible > presence of code that is unnecessary in some (perhaps > most) circumstances. It seems to me that the current specification of volatile already requires an lwsync around volatile reads and writes, to guarantee that all previous stores have been completed and later ones have not started. Jason
Re: Heads-up: volatile and C++
On Thu, 14 Apr 2005 17:11:58 +0100, Nathan Sidwell <[EMAIL PROTECTED]> wrote:
> Jason Merrill wrote:
>> 7 Accessing an object designated by a volatile lvalue (_basic.lval_),
>> modifying an object, calling a library I/O function, or calling a
>> function that does any of those operations are all side effects, which
>> are changes in the state of the execution environment. Evaluation of
>> an expression might produce side effects. At certain specified points
>> in the execution sequence called sequence points, all side effects of
>> previous evaluations shall be complete and no side effects of
>> subsequent evaluations shall have taken place.7)
>> My reading of this is that currently, a volatile read or write should act
>> as a barrier to other writes ("modifying an object"), because generally
>> there will be a sequence point between those writes and the volatile
>> access.
>
> Could you clarify whether 'other writes' means 'other _volatile_ writes',
> or '_any_ other writes'? Since non-volatile writes are not visible
> outside of the abstract machine, how can they be ordered wrt volatiles?
Any others. I was basing that on the requirement that the side-effects of
those writes are required to be complete, though I suppose you could argue
that they aren't required to be visible outside the current thread.
> It seems to me that threads require barriers _within_ the abstract machine,
> and currently there is no mechanism to specify just that. Volatile is all
> we have, and AFAICT those are only ordered WRT other volatile accesses
> separated by a sequence point.
>
> It appears to me that the proposal is providing more restrictions
> on volatile and other accesses, not fewer -- and cursorily that seems
> sane.
Yep.
Jason
Re: Heads-up: volatile and C++
On Thu, 14 Apr 2005 16:04:33 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote: > On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote: > >> But the memory model for the language must provide semantics that make it >> possible for threaded programs to be written. Currently, if you want to >> write a portable pthreads program you need to use a mutex around all uses >> of shared memory, because they are the only way to guarantee sequential >> memory ordering. The volatile proposal provides a lighter-weight way to >> write portable code with explicit memory ordering. You need this for >> lockless algorithms to work. > Not necessarily. Sequential memory ordering is not always > desirable. There exist concurrent algorithms out there that rely > on extremely weak memory ordering semantics for performance. I shouldn't have used the term "sequential memory ordering." Nobody is suggesting that C++ should enforce sequential consistency between threads. But even in the weakest memory models...*especially* in the weakest memory models, you need a way of making sure that you are up to date with the global state (in one of several senses) before you continue execution, and acquire/release semantics are a very convenient synchronization model. Consider Double-Checked Locking (http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html). I used DCL with explicit memory barriers to implement thread-safe initialization of function-local statics (libstdc++-v3/libsupc++/guard.cc). The proposed change to volatile semantics would allow me to write it more simply, by just making the initialized flag volatile. Yes, volatile would be stronger than is actually necessary for DCLP, but I don't have to use it if I want finer-grained control over the synchronization. > Seems to me that if C++ is all of the sudden interested in > dictating memory semantics for threaded programs, it should also > provide language capabilities for other synchronization models > and for threads (as in Java, though the memory model of Java used > to have problems of its own, dunno if they've been fixed). I believe the plan is to offer library functions which provide finer-grained control over synchronization primitives, but that volatile would be good enough for most uses, and easy to teach. > Anything else will only be an incomplete specification. > Particularly if it dictates stronger semantics on 'volatile', > which has been long used in chaotic situations where you either > don't care about synchronization or are doing it explicitly. The main reason I posted this now was to get more information about current uses of volatile, so I can block this proposal in the committee if necessary. I find it hard to believe that volatile is currently used in multithreaded code in ways that would be negatively impacted by this change, but I'm very interested in examples. The device driver case seems like a more plausible objection to me, but I'd like to see an example there, too. Jason
Re: Heads-up: volatile and C++
On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar <[EMAIL PROTECTED]> wrote: > [Ada standard] Yep, sounds a lot like C/C++: volatile reads and writes are required to have sequential ordering relative to each other, but (outside the current thread) they are not ordered relative to non-volatile reads and writes. Jason
Re: Heads-up: volatile and C++
On Thu, 14 Apr 2005 15:26:32 -0400, "Michael N. Moran" <[EMAIL PROTECTED]> wrote: > Again, I understand the need for ordering/synchronization, I > simply do not believe that volatile should be overloaded to > include these semantics. > > Part of my point is that there are existing uses of volatile > which whose performance would suffer should ordering and/or > synchronization instructions be added around each access. > > For example, device drivers that perform memory mapped I/O > on memory spaces which are "guarded" and thus need no additional > ordering/synchronization instructions. You mentioned PowerPC in a previous post; while device memory doesn't need as much explicit ordering as cached memory, http://www-128.ibm.com/developerworks/eserver/articles/powerpc.html says All these rules don't prevent stores to device memory from being issued out of program order with respect to loads from device memory, or vice versa. Instead, the memory-barrier instructions, eieio and sync, must be used when out of order operations could yield incorrect results. you need an eieio between loads and stores, or between two loads, to ensure proper ordering. Yes, the proposed volatile semantics are more than you need. But you do need something. That said, perhaps the current volatile semantics are a useful primitive for building on with more specific explicit ordering, but that's not clear to me. Jason
Re: Heads-up: volatile and C++
On Thu, 14 Apr 2005 23:11:03 -0400, Diego Novillo <[EMAIL PROTECTED]> wrote: > Again, not always. Consider chaotic asynchronous algorithms > (like variations of simulated annealing). They need no locks nor > any other kind of synchronization, though sometimes they'll use > some form of control synchronization to delimit phases. > > When implementing them in a shared-memory multithreaded > environment, they typically mark shared data as 'volatile' to > prevent the compiler from optimizing those references away. The properties of asynchronous algorithms are independent of memory model; even asynchronous algorithms expect to get updates from other threads all at once. If one thread writes out a new data set and another thread reads in an arbitrary subset of it, thinking it is the complete set, the algorithm will break. With a weak memory model, some sort of explicit memory ordering is necessary to ensure that all writes to that area are visible before reads begin. I believe that the current standard volatile semantics mean that if you mark all shared data as volatile, you enforce sequential access to all shared data, which will accomplish the necessary ordering but is stronger than you need. With the proposal only the last write and first read from the data need to be volatile, and the compiler and machine have more freedom to reorder the other accesses. I also believe that current compilers don't actually implement my interpretation of current semantics on most targets, and as a result marking the shared data as 'volatile' does not accomplish the necessary memory ordering, and the algorithm is likely to break without memory barrier asms. I think that with most compilers 'volatile' restricts reordering by the compiler, but not by the hardware, and so code that relies on 'volatile' alone will break on targets with a weak memory model. You seem to be conflating synchronization (via locks or otherwise) with explicit memory ordering; they are not the same. Synchronization involves threads waiting for each other to catch up; this proposal just means that at a release point all pending memory accesses are visible before a volatile write, and a volatile read happens before all subsequent memory accesses. This is strictly a thread-local property, and does not imply any waiting on another thread. I suppose using the terms 'acquire' and 'release' mislead people to think about locks, when no locks or other synchronization are implied. Some sort of coherent memory ordering is necessary for synchronization, but it is also necessary for asynchronous algorithms. > Right, but it would take away the traditional semantics of volatile. Why > not use some new language construct (monitors, set/wait) or even > templates to implement synchronization? Yes, actual synchronization is properly implemented by a library. > That's the only thing that I find disturbing about the proposal. > Overloading a very well established keyword with a new meaning. > I don't think it's going to be well received, that's all. Because it's very close to the current semantics, which IMO already impose ordering on volatile accesses (though compilers don't enforce that). The change is to define how volatile accesses are ordered relative to non-volatile accesses. I don't think it's a large conceptual change. A naive implementation would result in more overhead, but we should be able to optimize most of it away. > http://www.cs.ualberta.ca/~jonathan/Grad/Papers/aphidiee.ps > http://web.nchu.edu.tw/~jlu/research/papers/asynch.ps > > Note that the initial motivation for many of these techniques was to > yield good results on distributed systems. But if you were to implement > them in a multithreaded environment with shared data instead of message > passing, they'd declare the shared data volatile. Again, I don't think this is enough with current compilers and hardware. And with the proposal only the flag which indicates that a new data set is ready would need to be volatile. Jason
Re: Java field offsets
On Tue, 19 Apr 2005 18:03:58 -0700, Per Bothner <[EMAIL PROTECTED]> wrote: > Does Dwarf support "computed field offsets"? DWARF 2 does, yes. Jason
Re: GCC 4.1: Buildable on GHz machines only?
On Apr 27, 2005, at 12:57 PM, Steven Bosscher wrote: Maybe the older platform should stick to the older compiler then, if it is too slow to support the kind of compiler that modern systems need. This is an unreasonable request. Consider NetBSD, which runs on new and old hardware. The OS continues to evolve, and that often requires adopting newer compilers (so e.g. other language features can be used in the base OS). The GCC performance issue is not new. It seems to come up every so often... last time I recall a discussion on the topic, it was thought that the new memory allocator (needed for pch) was cause cache-thrash (what was the resolution of that discussion, anyway?) -- thorpej
Re: GCC 4.1: Buildable on GHz machines only?
On Apr 27, 2005, at 7:41 AM, David Edelsohn wrote: GCC now supports C++, Fortran 90 and Java. Those languages have extensive, complicated runtimes. The GCC Java environment is becoming much more complete and standards compliant, which means adding more and more features. Except it's not just bootstrapping GCC. It's everything. When the NetBSD Project switched from 2.95.3 to 3.3, we had a noticeably increase in time to do the "daily" builds because the 3.3 compiler was so much slower at compiling the same OS source code. And we're talking almost entirely C code, here. -- thorpej
Re: GCC 4.1: Buildable on GHz machines only?
On Apr 30, 2005, at 12:33 PM, Giovanni Bajo wrote: I would also like to note that I *myself* requested preprocessed source code to NetBSD developers at least 6 times in the past 2 years. I am sure Andrew Pinski did too, a comparable amound of times. These requests, as far as I can understand, were never answered. This also helped building up a stereotype of the average NetBSD developer being "just a GCC whine troll". While I have not had much time for a quite a while to work on GCC myself, I am listed as NetBSD maintainer... you can always drop me a note directly when this sort of thing happens. -- thorpej
Re: GCC 4.1: Buildable on GHz machines only?
A little humor from a long time ML lurker... Via C3-2 Nehemiah 1GHz 512MB ddr $ ../gcc-4.0.0/configure --prefix=/home/jason/local/gcc-400 --enable-shared \ --enable-threads=posix --disable-checking --enable-long-long --enable-__cxa_atexit \ --enable-clocale=gnu --disable-libunwind-exceptions --enable-languages=c --with-system-zlib $ time make bootstrap ... 3860.71user 245.24system 1:10:05elapsed 97%CPU 0inputs+0outputs (6698major+12862842minor)pagefaults 0swaps $ strip gcc ; upx -9 gcc ; ls -l gcc -rwxr-xr-x 1 jason jason 42672 May 5 23:07 gcc So the bootstrap process generates a useful 10 bytes/second. ;-) But seriously, GCC and various language standards have kept up with modern hardware. If someone takes a GCC release and hacks up a release to run on 50MHz boxes from years gone by, that's great, but I think the main GCC devs shouldn't worry about it because GCC is more about flexibility and extensibility than slim and trim I'd say. Perhaps there should be an "embedded GCC" team that focuses on a separate light-weight C/C++ project. Many thanks for GCC! -Jason, back to lurking.
GCC 4.0.0 Performance Regressions?
Is anybody collecting information on performance regressions in 4.0.0 (vs.
3.4.3)? I've got some results on POVRAY and BYTEmark, and BYTEmark saw some
performance regression, particularly with profiled optimization
(-fprofile-{generate,use}):
http://forums.gentoo.org/viewtopic-t-329765.html
I looked at the Bugzilla bug posting guidelines, but I don't know how to
boil this down to a tight testcase that fits those guidelines... and most of
what I saw in Bugzilla pertained to actual breakage anyway.
I'm willing to help out with this if I can get some pointers on what would
be useful to you--and if I can get the time away from my Real Work(TM) to
fiddle with this...
Jason B.
--
"My interest is in the future; I am going to spend the rest of my life
there."
-- Charles Kettering
Re: GCC 4.0.0 Performance Regressions?
On Tue, May 10, 2005 at 02:04:37AM +0200, Giovanni Bajo wrote: > You should try and isolate a single BYTEmark test which shows the biggest > regression. It's better if you manage to pack the whole test as a single > preprocessed source file. Theoretically, this file should be compilable and > linkable, and the resulting binary should run for a while doing computations. > > With this kind of help, we can analyze the regression and see why it's slower > with 4.0.0. > > Giovanni Bajo It was rather time-consuming but I managed to do it. I picked the numsort benchmark which had a serious regression: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485 Jason B. -- "My interest is in the future; I am going to spend the rest of my life there." -- Charles Kettering
Re: GCC 4.0.0 Performance Regressions?
On Tue, May 10, 2005 at 11:46:38AM +0200, Giovanni Bajo wrote: > Jason Bucata <[EMAIL PROTECTED]> wrote: > > >> You should try and isolate a single BYTEmark test which shows the > >> biggest regression. It's better if you manage to pack the whole test > >> as a single preprocessed source file. Theoretically, this file > >> should be compilable and linkable, and the resulting binary should > >> run for a while doing computations. > >> > >> With this kind of help, we can analyze the regression and see why > >> it's slower with 4.0.0. > > > > It was rather time-consuming but I managed to do it. I picked the > > numsort benchmark which had a serious regression: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21485 > > > Many, many thanks! > > Giovanni Bajo Would it help to report some others? I might have time later this week to work on some of the others, especially now that I have a much better idea of what to look for. OTOH I don't want to bother if the fix for this regression is likely to impact the other regressions, too... unless these test cases later get turned into regression tests for the compiler test suite or something. Would it make a big difference to grab and use the latest snapshot, like the bug guidelines suggest? I'll give it a try if it really makes a big difference to the optimizer detectives, but if it doesn't help I won't waste my time. Jason B. -- "My interest is in the future; I am going to spend the rest of my life there." -- Charles Kettering
Re: GCC 4.0.0 Performance Regressions?
On Tue, May 10, 2005 at 05:52:40PM -0700, Joe Buck wrote: > On Tue, May 10, 2005 at 06:08:43PM -0500, Jason Bucata wrote: > > Would it help to report some others [regressions]? > > I might have time later this week to > > work on some of the others, especially now that I have a much better idea of > > what to look for. > > If you can find a small test with a large regression (say 30% or more), it > would be great to have a PR for such a thing. All else being equal, > smaller test cases are easier to debug, so I'd suggest starting with as > small a test as possible that causes as large a regression as possible, if > you have any like that. OK, two more bugs posted: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21507 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21527 That's it for this batch, unless somebody wants me to chase down the other problem noted in 21527. I noticed some 4.0.0 regressions in SciMark noted here: http://www.coyotegulch.com/reviews/gcc4/index.html So I've thought I might try to chase down the regressions in Sparse MIPS and LU MIPS... but that will have to wait a while while I catch up on other things. Jason B. -- "My interest is in the future; I am going to spend the rest of my life there." -- Charles Kettering
Re: Compiling GCC with g++: a report
On Mon, 23 May 2005 23:25:13 -0700, Mark Mitchell <[EMAIL PROTECTED]> wrote: > Good point; yes, you would have to pass a pointer. I guess you could > create a singleton representative of each value in the enum, and pass > them around, but I agree that's getting pretty ugly. Of course, the > problem with "unsigned int" is that it is a complete type, and people can > accidentally pass in "7", even if there's no such enumeral. You really > want forward-declared enums, but you haven't got them; it may be you just > lose. :-( You don't have foward-declared enums because you don't know how large they need to be. If what you want is an opaque enum, such that other files treat it as an integer and only certain files know the enumerators, then declare your variables to some typedef of an integer. People could accidentally pass in "7" anyway in C. You either get the opacity or the type checking (when compiled as C++), but not both. Jason
Re: Compiling GCC with g++: a report
On Tue, 24 May 2005 17:32:27 -0700, Zack Weinberg <[EMAIL PROTECTED]> wrote: > On Tue, 2005-05-24 at 20:11 -0400, Daniel Jacobowitz wrote: >> If that's why you were confused by my response, I was not suggesting >> freezing the ABI. I think it's an awful idea. > > Why? To be honest, I keep harping on this mostly because I think it > should happen. All the C++-in-GCC noise is a digression. The problem is that for a library that uses inlines and templates extensively, the implementation is the interface, and so a change of implementation frequently results in an ABI change. So we can't freeze the library ABI until we're willing to commit to the implementation. C++ is much less friendly to separate compilation than C, at least if you use templates. Jason
RE: gcc template error?
I suspect this line is the source of your problems:
friend T* func(T* p);
Y isn't a template parameter here, but a (concrete?) class named "Y".
The below compiles with 3.4.3 anyways...
Regards,
-Jason
// Line 1
class A {
public:
A() { };
~A() { };
};
class B {
public:
B();
B(const A& a) { };
~B();
};
template class T;
template
T* func(T* p);
template class T {
X*m_;
public:
T(X* x) : m_(x) { };
~T() { };
friend T* func(T* p);
};
template
T* func(T* p) {
return (new T(new X(*p->m_)));
}
int main() {
A* a = new A();
T*p = new T(a);
T*q = func(p);
return 0;
}
Re: Reducing debug info for C++ ctors/dtors
On Mon, Jul 11, 2005 at 08:56:36PM -0400, Daniel Jacobowitz wrote: > > However, it is good enough to have > > > > .stabs "Base1:Tt(0,41)=s4x:(0,9),0,32;getx::(0,44)=#(0,41), > > (0,9),(0,43)=*(0,41),(0,36);:_ZN5Base14getxEv;2A.;;",128,0,1,0 > Eh, no. You have just lost any information about what constructors > were declared in the class. Yeah, Devang didn't present what we're doing here on the debug side too well. We're giving up a bit of information from within gdb -- it won't know what constructors and destructors a class has defined -- for a large savings in debug info (this can be over 20% of an application's debug info when lots of templates are in heavy use). Because the FUN stabs are still present, gdb knows about the constructors; it can step into them, it can set breakpoints on them. For most developers, this isn't a worthwhile tradeoff, but for a certain class of appliations the stabs debug info is enormous and this helps to ameloriate that by giving up a small bit of gdb functionality. This won't be enabled by default even within Apple, but it is a useful option to have available. Jason
Re: Reducing debug info for C++ ctors/dtors
On Mon, Jul 11, 2005 at 09:18:22PM -0400, Daniel Jacobowitz wrote:
> Thanks for the explanation. That makes more sense. Personally, if
> you're going to do this, I don't see why you're keeping debug info for
> methods; either ditch all artificial methods (including defaulted
> constructors but not manually specified constructors), or ditch all
> methods.
We considered that too.
On the question of artifical-vs-actual c/dtors, that's one breakdown
I don't have hard numbers on yet, but my argument is that gdb's
knowledge of a class' cdtors is only useful when you're ptype'ing
that class -- you rarely find yourself needing to call the constructor
or destructor on an object from the gdb CLI. And these things are
awfully long in stabs. So this is the kind of minor functionality
that the user can be told "turn this switch on and ptype of the
class won't be accurate" and they'll understand the trade-off.
As for ditching methods, this quickly turns into a loss of functionality
because users can no longer call methods on on object from the gdb
command line. Many users don't know about inferior function calls,
but the Apple debugger UI exposes a feature that sits on top of
those ("custom data formatters"), where you can specify how objects
of a given type should be displayed in the variables window. For
complex OO types, these are often expressions involving an inferior
function call.
Jason
Re: MEMBER_TYPE and CV qualifiers
I think that the underlying problem here, as with pointers to data members, comes from using POINTER_TYPE in the first type. Pointers to members are not pointers, and so using POINTER_TYPE just causes confusion. Jason
Re: Severe problems with vectorizing stuff in 4.0.3 HEAD
On Fri, Oct 14, 2005 at 01:43:03PM -0700, Kean Johnston wrote: > Also, when you say "stack going into main is 16 byte aligned", > what specifically do you mean? that its 16-byte aligned before > the call to main() itself? That at the first insn in main, most > likely a push %ebp, its 16-byte aligned (i.e does the call > to main from crt1.o have to take the push of the return address > into account)? The stack alignment is computed before the saved-EIP is pushed on the stack by a CALL instruction. So on function entry, the ESP has already been decremented by 4 off of its 16-byte alignment. Conventioanlly the EBP is pushed, making the ESP 8 bytes off its 16-byte alignment. If your ABI does not require 16-byte stack frame alignment, aligning it correctly in main() will not fix all the problems unless you can recompile all of the code (and fix all the hand-written assembly) on the entire system. If you're 16-byte aligned and you call into a library that only requires 4-byte alignment (the traditional SysV x86 ABI--Pinski says it's been updated to require 16-byte alignment but I don't know when that happened) and that library function calls into a newly-gcc-recompiled function, you can crash over there because of a misaligned operation. J
Re: incomplete type return types
Gabriel Dos Reis wrote: Would prefer to have build_function_type() also modified to be nice to error_mark_node? Yes, I see no reason for it not to. Jason
Re: Example of debugging GCC with toplevel bootstrap
Paolo Bonzini wrote: So, how would I now get a cc1plus/f951/jc1/cc1 binary compiled by the stage0 (host) compiler? make stage1-bubble STAGE1_LANGUAGES=c,c++,fortran,java Wow, that's awkward. I think that after I fix PR25670, as a side effect, you will also be able to use the more intuitive target "all-stage1". But I didn't think of that PR much closely because it is about a target that was anyway undocumented, and there are bigger fish to fry. Remind me why it's a good idea to force me to mess with bootstrapping at all, when all I want is to build a copy of the compiler that I can use for debugging problems? There has to be an easier way to do that. My laptop builds stage1 reasonably fast, but a bootstrap takes several hours. This is a serious regression for me. Jason
Re: Example of debugging GCC with toplevel bootstrap
Steven Bosscher wrote: ... you can use --disable-bootstrap and do a regular make, or is there some reason why you can't do that? I wasn't aware of the option. Guess I'll do that, then. Jason
Re: Help with new GCC git workflow...
On Tue, Jan 14, 2020 at 12:12 PM Jonathan Wakely wrote:
> On 14/01/20 10:07 -0600, Peter Bergner wrote:
> >As somewhat of a git newbie and given gcc developers will do a git push of
> >our changes rather than employing a git pull development model, I'd like
> >a little hand holding on what my new gcc git workflow should be, so I
> don't
> >screw up the upstream repo by pushing something to the wrong place. :-)
> >
> >I know enough that I should be using local branches to develop my changes,
> >so I want something like:
> >
> > git checkout master
> > git pull
> > git checkout -b
> >
> > git commit -m "My commit message1"
> >
> > git commit -m "My commit message2"
> >
> > git commit -m "My commit message3"
> >
> >
> >At this point, I get a little confused. :-) I know to submit my patch
> >for review, I'll want to squash my commits down into one patch, but how
> >does one do that?
>
> This is Git, there are a hundred ways ;-)
>
>
> >Should I do that now or only when I'm ready to
> >push this change to the upstream repo or ???
>
> Totally up to you. You might want to squash some commits early, e.g.
> to fix silly typos, but keep most of the branch history intact until
> the last minute (to help you remember what you changed and why).
> That's my preference.
>
> >Do I need to even do that?
>
> If it's a long-lived feature branch you might want to keep the
> separate commits and merge them all to master preserving the branch
> history (don't take my word for it, I can't remember what we decided
> should be the policy for such long-lived branches).
>
I think we're prohibiting merges to master. We definitely don't want
merges of branches with commits that don't each satisfy the normal rules
for commits.
If it's just a short-lived branch to change one thing, or fix one bug,
> then what you push should be a single, self-contained commit (even if
> you happened to develop it as a series of mini-commits locally).
>
> >Also, when I'm ready to push this "change" upstream to trunk, I'll need
> >to move this over to my master and then push.
>
> Strictly speaking, you don't need to. You can push that branch
> directly to master: git push origin HEAD:master
> That will fail unless the current branch is up-to-date with master,
> but would work fine if you've already rebased your branch on master,
> or if master hasn't moved since you branched.
>
> >What are the recommended
> >commands for doing that? I assume I need to rebase my branch to
> >current upstream master, since that probably has moved forward since
> >I checked my code out.
>
> You can either rebase on the new master (i.e. bring the new stuff from
> master into your branch) or the other way around (bring the stuff from
> your branch into master).
>
> A pretty straightforward way to do the second way is:
>
> git checkout master
> git pull
> git merge --squash
> [resolve any merge conflicts]
> [build + test again if your branch was behind master]
> git push
>
> i.e. pull the changes from your branch onto master, then push.
>
> This leaves your branch untouched, so you still have
> all the history locally for future reference.
>
> There are other ways e.g. 'git rebase --interactive master' and
> squash all the commits in the branch that way. Interactive rebases are
> awesome, and very useful. It's a fairly manual process, but that gives
> you full control. Get familiar with it.
>
> Or, to (non-interactively) rebase your branch on master (which you
> might want to do periodically anyway, before you're ready to push
> upstream):
>
> git checkout master
> git pull
> git checkout
> git rebase master
> [resolve any merge conflicts]
> [build + test]
>
> That's rebased your branch, but not actually squashed the branch
> commits yet. You can do that by checking out master and doing a
> merge --squash (as above) or just on the branch:
>
> # make this branch's committed state (aka "index") the same as master
> git reset master
> # but that didn't touch the content of the working directory,
> # that still matches your branch, so you can add+commit all the
> # files in the working dir that differ from the "index":
> git add --all
> git commit
>
If you use git reset --soft you don't need to add again. I use this alias
all the time to combine commits:
sq = "!f(){ git reset --soft ${@:-HEAD^} && git commit --amend -C
HEAD; }; f"
this combines all the commits since into the argument commit (or the
penultimate commit, if not specifie).
> This alters your branch's history to be a single commit against
> master, which contains all the changes that you'd done on the branch.
> I've never used this method, so I hesitate to recommend it. It's the
> least obvious way IMO.
>
> And after either of the rebase methods, you still need to get that
> single commit onto master to push (unless you're going to push
> directly from the branch). So that might be a reason to prefer doing a
> "merge --squash" to squash at the same time as pulling the changes
> int
Re: git conversion in progress
On Tue, Jan 14, 2020 at 9:56 AM Andreas Schwab wrote: > On Jan 14 2020, Martin Jambor wrote: > > > On Tue, Jan 14 2020, Andreas Schwab wrote: > >> On Jan 14 2020, Georg-Johann Lay wrote: > >> > >>> git clone --reference original-gcc ... > >> > >> Don't use --reference. It is too easy to lose work if you don't know > >> what you are doing. > > > > What are the risks, assuming I won't delete the referenced repo which > > sits on the same partition of the same local disk as the new one? > > The risk is if the original repository is gc'd (and nowadays git > automatically runs git gc --auto from time to time) it may lose objects > that are still needed by the referencing repository. That doesn't > happen with git worktree as the main repository knows about all > references, including worktree local reflogs. > Exactly. I used --reference with my local copy of the old git mirror, and it's hopelessly corrupt now due to needed objects getting gc'd from the reference repository. Very much not for use by novices without --dissociate. As the clone man page says, NOTE: this is a possibly dangerous operation; do not use it unless you understand what it does. If you clone your repository using this option and then delete branches (or use any other Git command that makes any existing commit unreferenced) in the source repository, some objects may become unreferenced (or dangling). These objects may be removed by normal Git operations (such as git commit) which automatically call git gc --auto. (See git-gc(1).) If these objects are removed and were referenced by the cloned repository, then the cloned repository will become corrupt. I notice that git.html on the website doesn't match what's currently in wwwdocs git, is automatic updating broken? Jason
Re: Help with new GCC git workflow...
On 1/14/20 5:45 PM, Jonathan Wakely wrote: On 14/01/20 17:05 +, Jonathan Wakely wrote: On 14/01/20 10:07 -0600, Peter Bergner wrote: As somewhat of a git newbie and given gcc developers will do a git push of our changes rather than employing a git pull development model, I'd like a little hand holding on what my new gcc git workflow should be, so I don't screw up the upstream repo by pushing something to the wrong place. :-) I know enough that I should be using local branches to develop my changes, so I want something like: git checkout master git pull git checkout -b git commit -m "My commit message1" git commit -m "My commit message2" git commit -m "My commit message3" At this point, I get a little confused. :-) I know to submit my patch for review, I'll want to squash my commits down into one patch, but how does one do that? This is Git, there are a hundred ways ;-) Should I do that now or only when I'm ready to push this change to the upstream repo or ??? Totally up to you. You might want to squash some commits early, e.g. to fix silly typos, but keep most of the branch history intact until the last minute (to help you remember what you changed and why). That's my preference. Do I need to even do that? If it's a long-lived feature branch you might want to keep the separate commits and merge them all to master preserving the branch history (don't take my word for it, I can't remember what we decided should be the policy for such long-lived branches). If it's just a short-lived branch to change one thing, or fix one bug, then what you push should be a single, self-contained commit (even if you happened to develop it as a series of mini-commits locally). Also, when I'm ready to push this "change" upstream to trunk, I'll need to move this over to my master and then push. Strictly speaking, you don't need to. You can push that branch directly to master: git push origin HEAD:master That will fail unless the current branch is up-to-date with master, but would work fine if you've already rebased your branch on master, or if master hasn't moved since you branched. What are the recommended commands for doing that? I assume I need to rebase my branch to current upstream master, since that probably has moved forward since I checked my code out. You can either rebase on the new master (i.e. bring the new stuff from master into your branch) or the other way around (bring the stuff from your branch into master). A pretty straightforward way to do the second way is: git checkout master git pull git merge --squash [resolve any merge conflicts] I forgot to say that you'll need to do 'git commit' after the merge, whether or not there were conflicts to resolve. When you merge with --squash it adds the squashed result to the "index" (i.e. staging area for changes to be committed) but stops before the actual commit. When you do the commit Git will start the commit message with all the individual commit messages from the branch: Squashed commit of the following: commit d308da36d957feb3736be2754d134926992b3b74 Author: Jonathan Wakely Date: Tue Jan 14 22:32:45 2020 + 3rd commit message commit 3d4a8783ba7f6d466d1729b59436a96b67ddf516 Author: Jonathan Wakely Date: Tue Jan 14 22:32:40 2020 + 2nd commit message commit e0a27b98135936d4129876babdbe81e22e6e9bbf Author: Jonathan Wakely Date: Tue Jan 14 22:32:34 2020 + 1st commit message So that's a good time to produce the final commit message, cutting and pasting bits from those if needed, or just deleting those lines. However, on IRC some people are saying that the simple workflow we should be advising for newbies is to rebase and squash on the branch (maybe using Jason's 'git reset' command) Probably easiest to focus on rebase -i. And perhaps git add -p for splitting a commit. and then cherry-pick that onto master (instead of squash-merging). A cherry-pick takes a single commit from another branch and applies it to the current branch, roughly equivalent to creating a patch and then manually applying it. If the branch has been reshaped to be all master-ready commits, you can push the branch directly, or rebase your local master on top of it rather than cherry-pick. Jason
Re: Help with new GCC git workflow...
On 1/15/20 4:55 AM, Jonathan Wakely wrote: On Wed, 15 Jan 2020 at 09:49, Richard Biener wrote: On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely wrote: On Wed, 15 Jan 2020 at 08:40, Richard Biener wrote: On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote: Peter Bergner : At this point, I get a little confused. :-) I know to submit my patch for review, I'll want to squash my commits down into one patch, but how does one do that? Should I do that now or only when I'm ready to push this change to the upstream repo or ??? Do I need to even do that? If you want to squash a commit series, the magic is git rebase -i. You give that a number of commits to look back at at and you'll get a buffer instructing you how to squash and shuffle that series. You'll also be able to edit the commit message. I like to write really fine-grained commits when I'm developing, then squash before pushing so the public repo commits always go from "tests pass" to "test pass". That way you can do clean bisections on the public history. The question is wheter one could achieve this with branches? That is, have master contain a merge commit from a branch that contains the fine-grained commits? Because for forensics those can be sometimes useful. A "merge commit" is a special kind of commit that creates a commit with two (or more) parents, and joins two separate trees. We don't allow that in master or release branches. But you can definitely take a series of commits from a branch and put that whole series into master, without squashing them into one commit. You just have to rebase the patches onto master (or cherry-pick each one of the series in turn, but rebase is easier for multiple patches). That makes a series of new commits on master, each one corresponding to one of he commits in the branch (but new commits with new hashes, because the new commit has a different parent than the one on the branch did). That's fine, but it's not a "merge commit". That basically would somehow record that a series of commits are "related" (the merge commit has two parents). Of course usually the merge commit is empty and thus non-existant but then for branch merges it still always exists? A merge commit might be empty, but it's not non-existent. But we don't allow merge commits on master, and we don't need to allow them in order to have a series of related commits go in together. OK, I see. Guess we should document to not think that a git push of a series represented as multiple commits are a "single" commit on master Well yes, because if you push a series of commits then you push ... a series of commits. When you push something upstream you make the upstream repo have exactly the same commits as you have locally. There is no squashing or flattening involved. The remote repo's HEAD becomes the same commit ID as your HEAD. (Before an expert corrects me: strictly speaking, the remote's branch becomes whatever you push, which doesn't have to be HEAD because you could do 'git push origin some_commit_hash:master' but in the common case you just push your HEAD and that becomes the new branch tip on the remote). then and that if you do that individual commits need to be bootstrapped and tested. So, maybe prevent pushes of multiple commits for safety? Please no! As for not allowing merges I guess we could eventually relax this to allow merge commits that are "empty" and the referred refs have linear history from the merge parent? There's no point. If you have a simple linear history where each commit has a single parent, there is no merge commit. The only point is the grouping richi mentions. To that purpose we *could* allow --no-ff merges that otherwise would have been fast-forward, but allowing such merges without allowing any other merges would be difficult to enforce. I don't think it's worth bothering. Jason
Re: gcc-cvs mails for personal/vendor branches for merge commits
On 1/15/20 9:56 AM, Joseph Myers wrote: On Wed, 15 Jan 2020, Jakub Jelinek wrote: Or, if that is not possible, disable gcc-cvs mail for vendor and private branches altogether? I think this is desirable. gcc-cvs should only mail about changes to master and release branches. Jason
Re: gcc-cvs mails for personal/vendor branches for merge commits
On 1/15/20 11:30 AM, Joseph Myers wrote: On Wed, 15 Jan 2020, Jason Merrill wrote: On 1/15/20 9:56 AM, Joseph Myers wrote: On Wed, 15 Jan 2020, Jakub Jelinek wrote: Or, if that is not possible, disable gcc-cvs mail for vendor and private branches altogether? I think this is desirable. gcc-cvs should only mail about changes to master and release branches. I thinks commit mails for changes to all branches are desirable (including refs/heads/devel/ branches, including user and vendor branches) - but they should only be for changes that are new to the repository. Existing practice in SVN was that all branches generated mails, we simply didn't have so many branches. User branches in particular are likely to be very messy in the git world; in the old git mirror I would occasionally push a personal branch with work-in-progress patches that aren't nicely organized. Perhaps one mail per push for those branches, rather than one per commit? Jason
Re: gcc-cvs mails for personal/vendor branches for merge commits
On 1/15/20 11:37 AM, Iain Sandoe wrote: Joseph Myers wrote: On Wed, 15 Jan 2020, Jason Merrill wrote: On 1/15/20 9:56 AM, Joseph Myers wrote: On Wed, 15 Jan 2020, Jakub Jelinek wrote: Or, if that is not possible, disable gcc-cvs mail for vendor and private branches altogether? I think this is desirable. gcc-cvs should only mail about changes to master and release branches. I thinks commit mails for changes to all branches are desirable (including refs/heads/devel/ branches, including user and vendor branches) - but they should only be for changes that are new to the repository. Existing practice in SVN was that all branches generated mails, we simply didn't have so many branches. For user/vendor branches that are rebased (a desirable action), is there any mechanism for excluding unchanged rebased commits from being seen as “new”? I’m guessing that public development branches will probably gravitate to the no non-FF mode, if they are to be used by people other than the primary author Except that long-lived public development branches will need to merge master periodically, and that will be a non-FF merge. Jason
Re: gcc-cvs mails for personal/vendor branches for merge commits
On 1/17/20 11:55 AM, Joel Brobecker wrote: AFAIU, we have access to more fine-grained information; isn’t it possible to differentiate “new” commits, from ‘merges’ and from ‘rebases’? (because a ‘new’ commit does not have the extra fields set up for merges and rebases). In my opinion, this would create a lot of complication for the benefits being gained. I also think that the more variations of behaviors you introduce, the harder is becomes for people to know what's right and what's not expected. People then start getting surprised and start asking about it. At best, it's just a quick answer, but in some cases, it takes time to remember why we set things up the way they are and why it doesn't make sense to change it. Over the years, I have really learnt to enjoy the benefits of consistency, even if it is means some areas are suboptimal. The "suboptimality" can still be a better compromise overall than a superengineered system. Spamming the list with emails every time someone merges master to their development branch sounds highly suboptimal, and likely to lead to disabling email entirely for those branches. Is it so complicated to send a single email for a merge commit or non-fast-forward push? Jason
Re: gcc-cvs mails for personal/vendor branches for merge commits
On 1/17/20 12:59 PM, Iain Sandoe wrote: Joel Brobecker wrote: AFAIU, we have access to more fine-grained information; isn’t it possible to differentiate “new” commits, from ‘merges’ and from ‘rebases’? (because a ‘new’ commit does not have the extra fields set up for merges and rebases). In my opinion, this would create a lot of complication for the benefits being gained. I also think that the more variations of behaviors you introduce, the harder is becomes for people to know what's right and what's not expected. People then start getting surprised and start asking about it. At best, it's just a quick answer, but in some cases, it takes time to remember why we set things up the way they are and why it doesn't make sense to change it. Over the years, I have really learnt to enjoy the benefits of consistency, even if it is means some areas are suboptimal. The "suboptimality" can still be a better compromise overall than a superengineered system. Spamming the list with emails every time someone merges master to their development branch sounds highly suboptimal, and likely to lead to disabling email entirely for those branches. Is it so complicated to send a single email for a merge commit or non-fast-forward push? Well, no. I was going so say that this is what I have been proposing all along, except the way you phrased your suggestion above makes me think that perhaps you want something more automatic, where the hooks decide dynamically, rather than the choice being made by configuration. So it's not exactly the same, but quite similar in spirit. I think we can find ways that will satisfy the need for fewer emails without having to have that extra logic, though. Also, you guys have to understand that you are all coming to me from multiple directions at the same time, and making requests that are not always easy to reconcile. I do completely understand that getting hundreds of emails because of a merge into a development branch is far from optimal, and it's absolutely not what I am suggesting we do here. In fact, you'll see that I told Joseph in a separate mail that I will think this over and try to come up with something that answers the situation he described. What I am alerting people to is trying to have special-case handling for every scenario we can conceive. for my part, I was not trying to specify “requirements” - but identify different scenarios that we might want to handle (better to decide how we want to do things at the start, than to create changes later). Indeed, this is largely a discussion about what is desirable and feasible. How straightforward a particular request will be is helpful feedback. Thank you, and sorry I got snarky above. Jason
Re: git: remote: *** The first line of a commit message should be a short description of the change, not a single word.
On Tue, Jan 21, 2020 at 11:52 AM Richard Earnshaw (lists) < richard.earns...@arm.com> wrote: > On 21/01/2020 16:43, Nathan Sidwell wrote: > > On 1/21/20 11:38 AM, Richard Earnshaw (lists) wrote: > >> On 21/01/2020 16:14, Jonathan Wakely wrote: > >>> On Tue, 21 Jan 2020 at 16:03, Martin Liška wrote: > >>>> > >>>> Can you please remove the hook for user branches likes: > >>>> > >>>> $ git push origin me/filter-non-common > >>>> Enumerating objects: 27, done. > >>>> Counting objects: 100% (27/27), done. > >>>> Delta compression using up to 16 threads > >>>> Compressing objects: 100% (14/14), done. > >>>> Writing objects: 100% (14/14), 1.77 KiB | 1.77 MiB/s, done. > >>>> Total 14 (delta 13), reused 0 (delta 0) > >>>> remote: *** The first line of a commit message should be a short > >>>> description of the change, not a single word. > >>>> remote: error: hook declined to update > >>>> refs/users/marxin/heads/filter-non-common > >>>> To git+ssh://gcc.gnu.org/git/gcc.git > >>>>! [remote rejected] me/filter-non-common -> > >>>> refs/users/marxin/heads/filter-non-common (hook declined) > >>>> error: failed to push some refs to 'git+ssh://gcc.gnu.org/git/gcc.git > ' > >>> > >>> Requiring slightly better messages than just a single word doesn't > >>> seem to restrictive to me, even on user branches. > > > > plus it teaches you good practice in a safe area. > > > >> I agree. What's more, if you ever want to merge the branch into trunk > >> you'll need to fix such messages, so why not just get them right in > >> the first place? > > > > Are you using 'merge' with some meaning other than git merge? because > > merging to trunk is verboeten. > > In the sense 'integrate' your change into trunk. In practice I mean by > a fast-forward push, of course. > My commit messages while I'm working on something rarely have anything to do with the commit messages that I eventually push to trunk; there's no point in writing extensive description of stuff I might discard anyway. When I'm done developing a change I then squash and reorganize commits and write the commit message for public consumption. Jason
Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions
On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote: On 21/01/2020 15:39, Jakub Jelinek wrote: On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) wrote: Some examples would be useful I'd say, e.g. it is unclear in what way you want the PR number to be appended, shall it be something: whatever words describe it PR12345 or something: whatever words describe it (PR12345) or something: whatever words describe it: PR12345 or something: whatever words describe it [PR12345] or something else? Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, I'm not too worried. I'd be happy with [PR #], but if folk want something else, please say so quickly... [PR 12345] or [PR #12345] is bad, because the bugzilla won't underline it, it needs to be either PR12345 word, or PR component/12345 . ok, lets go with [PR] then. Doesn't this use of [] have the same problem with git am? My summaries are often describing the bug I'm fixing, i.e. [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs. which is also the first line of my ChangeLog entry. I think you are proposing [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs (PR91476) which can no longer be shared with the ChangeLog. Jason
Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions
On Mon, Feb 3, 2020 at 7:57 AM Alexander Monakov wrote: > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > > Upper case is what glibc has, though it appears that it's a rule that is > not > > strictly followed. If we change it, then it becomes another friction > point > > between developer groups. Personally, I'd leave it as is, then turn a > blind > > eye to such minor non-conformance. > > In that case can we simply say that both 'committed' and 'COMMITTED' are > okay, > if we know glibc doesn't follow that rule and anticipate we will not follow > it either? > And perhaps something shorter? "committed" is a long word. [PUSHED]? Jason
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Thu, Feb 6, 2020 at 11:25 AM Segher Boessenkool < seg...@kernel.crashing.org> wrote: > > We also need a way to fix changelog entries for the errors that do seep > through (and that are bad enough that they do need fixing). It doesn't > have to be easy or convenient, but we need *some* way to do it. > git notes? Jason
Re: Git ChangeLog policy for GCC Testsuite inquiry
On Fri, Feb 7, 2020 at 1:44 PM Tom Tromey wrote: > > > "Jonathan" == Jonathan Wakely writes: > > Jonathan> I have a script that does the opposite, which I've been using for > Jonathan> years. I edit the ChangeLog files as before, and a Git > Jonathan> prepare-commit-msg hook extracts the top changelog entry from each > Jonathan> file in the commit and pre-populates my commit msg with those > entries. > > Jonathan> To use it just put the two prepare-commit-msg* files from > Jonathan> https://gitlab.com/miscripts/miscripts/-/tree/master/gcc into your > Jonathan> $GCC_SRC/.git/hooks directory. > > I do this too, combined with scripts to handle merge ChangeLogs > specially during rebase; scripts to update the dates on ChangeLog files > before pushing; and a wrapper for "git send-email" that strips the > ChangeLogs from the email (part of gdb patch submission rules). I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git send-email command. I don't remember where I found that incantation. > You can find it all here > > https://github.com/tromey/git-gnu-changelog > > Tom >
C++11 bootstrap (was: GCC selftest improvements)
On Thu, Feb 13, 2020 at 11:18 PM Modi Mo wrote: > > > On 2/12/20 8:53 PM, David Malcolm wrote: > > > Thanks for the patch. > > > > > > Some nitpicks: > > > > > > Timing-wise, the GCC developer community is focusing on gcc 10 > > > bugfixing right now (aka "stage 4" of the release cycle). So this > > > patch won't be suitable to commit to master until stage 1 of the > > > release cycle for gcc 11 (in April, hopefully). > > > > > Ah I should've looked a bit harder for timelines before asking > https://gcc.gnu.org/develop.html. Appreciate the response here! > > > > But yes, it's probably a good idea to get feedback on the patch given > > > the breadth of platforms we support. > > > > > > The patch will need an update to the docs; search for "Tools/packages > > > necessary for building GCC" in gcc/doc/install.texi, which currently > > > has some paragraphs labelled: > > >@item ISO C++98 compiler > > > that will need changing. > > > > > > I think Richi mentioned that the minimum gcc version should be 4.8.2 > > > as he recalled issues with .1, so maybe the error message and docs > > > should reflect that? > > > > > > https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html > > > > > Segher here suggests 4.8.5 instead of 4.8.2: > https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html > > Looking at release dates 4.8.5 was in June 2015 while 4.8.2 in October 2013 > which is a pretty big gap. I'd for moving the needle as far as we reasonably > can since this is a leap anyways. @Segher do you have a reason in mind for > the higher versioning? > > > This may be opening a can of worms that should wait until we're done > > > with the GCC 10 release, but there's probably an eventual wider > > > discussion about what parts of C++11 we should use; pragmatically > > > we're also limited by gengtype, the tool that scrapes the source code > > > looking for garbage-collector markup, as that imposes a subset of C++ on > > > us. > > > > > > I'd love to be able to rely on move semantics and thus use e.g. > > > std::unique_ptr to capture more of our memory-management in the type > > > system (we currently have a limited C++98-compatible implementation in > > > the tree in the form of gnu::unique_ptr). > > > > > > How much of the stdlib do we see ourselves using? I think we've > > > avoided std::string and the <<-style stream APIs; is there a case for > > > using some of the other data structures? > > > > > > For reference, see > > > > > > https://gcc.gnu.org/codingconventions.html#Cxx_Conventions > > > > > > Hope this is constructive. > > > Dave > > Dave, > > > > I recall originally bringing up the move. From memory I recall that these > > were > > the features we wanted or the people in the discussion wanted from C++11: > > 1. Better Rounding and Stricter Integer and other number type rules 2. > > Template > > Aliasing 3. Auto and for each style loops 4. Move and R Value Semantics > > > > Agreed on these features. I really like having access to 'for (const auto & > foo : bar)' > > There was a little discussion about lambas and anonymous functions but I > > don't > > recall that being clear in terms of one of the above areas for sure. For information, bootstrap with 4.8.5 -std=gnu++11 works now with no other changes. It seems the only other changes needed will be to documentation. Jason
ABI compatibility: GCC9 vs GCC10
Any notable ABI changes from 9 to 10? Thanks! -Jason (Sorry for asking here, there was no response from gcc-help in January.)
Re: GCC Bugzilla (and other) timeouts
On Wed, Feb 26, 2020 at 3:39 AM Jonathan Wakely wrote: > On Tue, 25 Feb 2020 at 18:25, Martin Sebor wrote: > > > > Bugzilla has been slow lately, and today to the point of timing out > > (I see the same problem with Git). This seems to be a recurring theme > > around the time of a GCC release. Is anyone else experiencing this > > problem and if so, does anyone know what the cause it and an ETA for > > a solution? Is the upcoming hardware upgrade expected to solve it? > > > > Thanks > > Martin > > > > $ git pull > > Connection closed by 209.132.180.131 port 22 > > fatal: Could not read from remote repository. > > > > Please make sure you have the correct access rights > > and the repository exists. > > What URL are you using to pull? (git remote get-url origin) > > Bugzilla and httpd are very slow, but I haven't had any git timeouts. > If you're using anonymous access that gets throttled more aggressively > than authenticated access (using git+ssh:// for the protocol). > Yes, I used to use git:// for pulls and ssh:// for pushes, but switched to ssh:// for both because I was getting too many rejected connections. 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
Subtyping support in GCC?
The the ARM compiler (armcc) provides a subtyping ($Sub/$Super) mechanism useful as a patching technique (see links below for details). Can someone tell me if GCC has similar support? If so, where can I learn more about it? FYI, before posting this question here, I researched the web extensivelly on this topic. There seems to be some GNU support for subtyping in C++. But I had no luck finding any information specifically for 'C'. Thanks, Jason How to use $Super$$ and $Sub$$ for patching data?: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15416.html Using $Super$$ and $Sub$$ to patch symbol definitions: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0474c/Chdefdce.html
Re: Subtyping support in GCC?
> GNU ld has an option --wrap=symbol. Does that roughly match your need? That seems to do the trick, even if that may require also modifying the Makefile for every wrapper function. > the best list would have been gcc-h...@gcc.gnu.org) Will do next time. Many thanks, Jason
