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
su
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] __attrib
The SC has appointed Jakub Jelinek as an additional maintainer of the
GNU OpenMP library (libgomp).
Jakub, please update MAINTAINERS accordingly.
Thanks!
Jason
Mark Mitchell wrote:
* PR 27945 (Merill)
* PR 30590 (Guenther, Merill)
I'll get on these.
Jason
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_addres
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
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 sl
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 eve
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
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
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 f
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 w
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 int
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 machin
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
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
>> func
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. 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
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 volatil
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 s
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
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
> prob
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 har
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
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
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 intuiti
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
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
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 w
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
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 po
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
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
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
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 wou
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
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 wrot
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
some
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 develope
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 d
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
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
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.
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
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_clas
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
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:
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 t
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
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 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
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/
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
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
migh
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
separa
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 (m
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
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
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
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
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
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
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 ol
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, b
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
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
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 gene
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 tr
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\"
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?
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
[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
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 lik
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
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
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
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
(fo
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 peo
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'
On Thu, Apr 21, 2016 at 12:47 PM, Jason Merrill wrote:
> On Thu, Apr 21, 2016 at 11:57 AM, Jonathan Wakely
> wrote:
>>
>> I once tried to write a gcc plugin that would check all names defined
>> by libstdc++ and ensure they were either in the reserved namespace, or
&
On Mon, May 9, 2016 at 5:18 AM, Jonathan Wakely wrote:
> On 8 May 2016 at 02:10, Christopher Di Bella wrote:
>> Hi all,
>>
>> I've been tracking gcc-digest for a bit, but would like to be a little
>> more involved in the development of gcc.
>>
>> I haven't been able to find anything about the CppC
On Tue, May 17, 2016 at 8:51 AM, Manuel López-Ibáñez
wrote:
> Please also note that, in terms of legal papers, the FSF is much more
> flexible than one may think, but they are not very pro-active or fast
> (in my past experience, things may have changed now). If you find some
> internal resistance
On Mon, May 30, 2016 at 3:15 PM, Patrick Palka wrote:
> Though there are some inconsistencies regarding the inclusiveness of
> -Wall seeing as neither -Woverlength-strings nor -Wempty-body are
> enabled by -Wall even though they seemingly satisfy the criteria of
> -Wall more readily than -Wmislead
On Sat, Jun 11, 2016 at 8:57 PM, Christopher Di Bella wrote:
>> I'm currently waiting on approval from my employer before I move ahead
>with anything
>
> My employer has given me the okay to contribute to gcc, provided that I
> follow some fairly straightforward rules. Most of these things are
On Thu, Jun 23, 2016 at 5:04 PM, David Malcolm wrote:
> Step 10: commit to svn
>
> Once the patch is approved, commit it to svn. (FWIW I do all of my
> development work in git; I have an svn checkout that I use purely for
> the final checkin, having smoketested the patch first).
Why not checkin
On Mon, Jul 4, 2016 at 12:09 PM, Frank Ch. Eigler wrote:
> jwakely.gcc wrote:
>
>> [...] (When we switched Fedora to using GCC 6, with C++14 enabled by
>> default, dozens and dozens of C++ packages failed to compile,
>> because even in 2016 nobody had ever tried to compile them with
>> C++11 featu
On Tue, Oct 4, 2016 at 4:29 PM, Zan Lynx wrote:
> On 10/04/2016 02:00 PM, Martin Sebor wrote:
>> This would have been easier if C++ had allowed the same default value to
>> be given in both the declaration and the definition:
>>
>> void foo(int x, int y, bool bar_p = false);
>>
>> void foo(int x,
On Wed, Oct 5, 2016 at 12:18 PM, wrote:
>> On Oct 5, 2016, at 12:12 PM, Jeff Law wrote:
>> On 10/04/2016 03:08 PM, Jason Merrill wrote:
>>> On Tue, Oct 4, 2016 at 4:29 PM, Zan Lynx wrote:
>>> ...
>>> In GCC sources, I think users look at the func
On Thu, Oct 6, 2016 at 1:19 PM, Eric S. Raymond wrote:
> Joseph Myers :
>> On Thu, 6 Oct 2016, Eric S. Raymond wrote:
>>
>> > I thought the gcc conversion was done.
>> >
>> > I can make the repository available again if it's needed.
>>
>> The conversion got stalled (I'm not sure why; maybe just Ja
On Thu, Oct 6, 2016 at 4:31 PM, Joseph Myers wrote:
> On Thu, 6 Oct 2016, Jason Merrill wrote:
>
>> After I ran into a couple of reposurgeon bugs and didn't hear back
>> from you, I started investigating rewriting the existing git svn
>> mirror with git filter-b
On Mon, Oct 10, 2016 at 6:38 AM, Jonathan Wakely wrote:
> On 7 October 2016 at 22:26, Joseph Myers wrote:
>> On Fri, 7 Oct 2016, Frank Ch. Eigler wrote:
>>> FWIW, I thought at one point the consensus was that the mailmap would
>>> expand only to $use...@gcc.gnu.org rather than $userid@$organizatio
On Tue, Oct 11, 2016 at 10:54 AM, Martin Sebor wrote:
> To close the loop on this thread, although there was mild support
> for both of these conventions there were also objections to both,
> including a suggestion for an alternative to the "/*foo_p=*/" style
> that would be preferred by most peop
On 06/02/2014 11:45 AM, Michael Meissner wrote:
I have not been following the language standards recently. For any of the
recent language standards, or the standards that are being worked on, will
there be requirements for an IEEE 128-bit binary floating point type? For the
C/C++ languages, is
On 07/20/2014 06:01 PM, Jakub Jelinek wrote:
On Sun, Jul 20, 2014 at 05:59:08PM +0100, Richard Biener wrote:
I understood we agreed on 5.0 and further 5.1, 5.2 releases from the
branch and 6.0 a year later. With unspecified uses for the patch level
number (so leave it at zero).
Ian/Jason, is
On 09/15/2014 11:21 AM, Ulrich Weigand wrote:
Jakub Jelinek wrote:
On Tue, Jun 10, 2014 at 07:37:50PM +0200, Ulrich Weigand wrote:
the following C++ test case:
struct pollfd
{
int fd;
short int events;
short int revents;
};
struct Pollfd : public pollfd { };
struct Pollf
On 09/15/2014 11:55 AM, Ulrich Weigand wrote:
(https://gcc.gnu.org/ml/gcc/2014-06/msg00116.html)
From the __builtin_object_size documentation, it's not immediately
clear to me whether this is supposed to work or not:
If the least significant
bit is clear, objects are whole variables, if
On 09/16/2014 06:23 AM, Ulrich Weigand wrote:
I guess I'm still a bit confused about the special handling of the array
case. Even with the last bit set, array elements normally do not count
as "subobjects", so __builtin_object_size still returns the size of the
full array.
I expect that's beca
On 09/16/2014 08:27 AM, Jason Merrill wrote:
On 09/16/2014 06:23 AM, Ulrich Weigand wrote:
Note that with a somewhat equivalent C construct:
struct pollfd
{
int fd;
short int events;
short int revents;
};
struct Pollfd
{
struct pollfd x;
};
struct Pollfd myfd
On 09/12/2014 08:04 PM, Jakub Jelinek wrote:
I've been worried about the quick cases where
parallelization is not beneficial, like make check-gcc \
RUNTESTFLAGS=dg.exp=pr60123.c or similar, but one doesn't usually pass -jN
in that case.
I have -jN in my $MAKEFLAGS, so I've been running into thi
On 09/22/2014 11:26 AM, Jakub Jelinek wrote:
On Mon, Sep 22, 2014 at 11:21:14AM -0400, Jason Merrill wrote:
If I say 'rgt dg.exp=var-templ1.C' the actual test results are lost in the
explosion of shell verbosity. Could we add some '@'s to more of the rules,
perhaps?
I
1 - 100 of 528 matches
Mail list logo
