On Thu, 9 Jan 2020, Joseph Myers wrote:
>> Is there any chance we could get one more trunk snapshot before the
>> conversion starts -- even if that means firing up the snapshot process
>> Friday? It'd be quite useful for the ongoing Fedora build testing.
> I could run a snapshot manually. I was p
On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
> I was wrong re. r182541, I didn't notice that it is the first commit on
> branch. This renders the analysis in favor of reposurgeon conversion,
> not svn-git.
Kudos for that statement, Maxim.
And thanks a bunch for all the work you have been doing,
On Sat, 11 Jan 2020 at 09:17, Gary Oblock wrote:
>
> I'm writing an LTO optimization that requires "-flto-partition=one" How can I
> make
> sure that this is the case? I've spent hours greping the code and the
> Internals Doc is
> worth less than nothing for something like this. If you have an a
On 10/01/20 10:25 pm, Alexander Monakov wrote:
> On Fri, 10 Jan 2020, Siddhesh Poyarekar wrote:
>
>> I spent some time thinking about this and while it's trivial to fix by
>> disabling ifuncs for static glibc, I wanted a solution that wasn't such
>> a big hammer. The other alternative I could thi
I'm writing an LTO optimization that requires "-flto-partition=one" How can I
make
sure that this is the case? I've spent hours greping the code and the Internals
Doc is
worth less than nothing for something like this. If you have an answer or even
I good idea of where to look please let me know.
The GCC SVN repository is now read-only for the move to git, as is the old
git-svn mirror; the cron job updating that mirror has been disabled, as
have gccadmin's cron jobs updating DATESTAMP, generating snapshots and
updating online documentation, until those are updated to work from git.
Assu
Richard,
Let me see if I've got this straight. Are you saying it's the
shape of objects combined with the variables that point at these
objects (or some subpart of them) that should drive struct reorg?
It seems to be hard to understand how to proceed from that notion
without something like types t
Snapshot gcc-8-20200110 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/8-20200110/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-8
On Fri, 10 Jan 2020, Jakub Jelinek wrote:
> We'll need to tweak maintainer-scripts/gcc_release in any case.
I now have a conversion of gcc_release to use git. Once the repository
conversion is done I'll test it for snapshot creation (which can be done
while the converted repository is still re
On Fri, Jan 10, 2020 at 02:15:30PM -0500, Jason Merrill wrote:
> Yep, this is a lot like I was suggesting at
>
>https://gcc.gnu.org/ml/gcc-patches/2019-08/msg01015.html
>
> except I didn't think it was necessary to trim the trailing SHA. I
> also suggested creating a tag for the beginning of
One further change I've made for the GCC hooks: rejecting commits whose
commit message's first line looks like a ChangeLog header (matches the
regular expression '[0-9]{4}-[0-9]{2}-[0-9]{2} .*<.*@.*>'). That should
help avoid people's habits writing such commit messages carrying over into
comm
On Fri, Jan 10, 2020 at 11:45 AM Jakub Jelinek wrote:
>
> Hi!
>
> As I said earlier, one thing I find useful in svn compared to git are
> the monotonically increasing revision numbers that we at Red Hat e.g. use
> in our gcc bisect seed but I find it useful even in bugzilla everyday use.
>
> With
On Fri, Jan 10, 2020 at 10:09:08PM +0400, Joel Brobecker wrote:
> > > As it is short, could it be something we'd put as first thing in the
> > > gcc-cvs
> > > mail subjects (of course, only for trunk and release branch commits; like
> > > the current svn mails start with rNN - ), and somewhere
> We could, it just feels like "branch names [in refs/heads/] must match one
> of these naming conventions" is something fairly generic rather than
> extremely GCC-specific.
I understand.
My fear is that we're discussing a lot of new configurations knobs.
And from experience, they can start int
On Fri, 10 Jan 2020, Joel Brobecker wrote:
> > No. What we want to ensure is that people don't accidentally create a
> > branch called refs/heads/foo when they should (by our naming conventions)
> > have created one called refs/heads/devel/foo or
> > refs/users/someone/heads/foo. Our naming c
> > > Plus one further change now: if a newly created branch is in refs/heads/,
> > > require it to be in refs/heads/devel/ or refs/heads/releases/ (i.e.
> > > enforce a particular branch naming convention, in particular to prevent
> > > mistakes where people accidentally push a branch into refs
On Fri, 10 Jan 2020, Joel Brobecker wrote:
> > Plus one further change now: if a newly created branch is in refs/heads/,
> > require it to be in refs/heads/devel/ or refs/heads/releases/ (i.e.
> > enforce a particular branch naming convention, in particular to prevent
> > mistakes where people
On Fri, Jan 10, 2020 at 05:47:16PM +, Joseph Myers wrote:
> > Ok, so what about basepoints instead?
>
> That seems a better name to me.
Ok.
> > > I think the existing git hook configuration expects you to push only
> > > annotated tags, not lightweight tags (so you'd need to use -a / -s / -
> > > I think the existing git hook configuration expects you to push
> > > only annotated tags, not lightweight tags (so you'd need to use -a
> > > / -s / -u when creating those tags).
> >
> > Ok, would use -a then; or do we plan to GPG sign some tags such as releases?
>
> I think signing future
> > We would need to add some tags (I wouldn't bother with pre-GCC 5 era,
> > because that doesn't have single number version numbers in the branch
> > names), like:
> > for r in 10 9 8 7 6; do
> > git tag branchpoints/gcc-$r `git rev-list $(git merge-base origin/master
> > origin/releases/gcc-$
> > Concretely, these are the changes I'm currently using to configure the
> > hooks in a way I think appropriate for GCC, and it would be useful if the
> > hooks could support such configuration in a more generic way in future so
> > that we can stop using a GCC-specific patched installation of
> * Additional branch namespaces refs/users//heads and
> refs/vendors//heads, and similar tag namespaces
> refs/users//tags and refs/vendors//tags.
Hmmm. Note to self: I missed the fact that this namespace was
also used for tags.
> * Only allowing branch deletion for certain ref patterns (refs/
On Fri, 10 Jan 2020, Jakub Jelinek wrote:
> > Those look like the start of GCC version N development (just after the
> > branchpoint for N-1), not the branchpoint as commonly understood; naming
> > them "branchpoints" seems confusing.
>
> Ok, so what about basepoints instead?
That seems a bett
Hi Joseph,
Apologies for the slow replies. The end of this week has been
pretty packed, and next week will be as well. But I will make
sure we answer every questions and suggestions you have!
On Thu, Jan 09, 2020 at 02:25:59PM +, Joseph Myers wrote:
> On Mon, 16 Sep 2019, Joel Brobecker wrote
On Fri, Jan 10, 2020 at 05:05:04PM +, Joseph Myers wrote:
> On Fri, 10 Jan 2020, Jakub Jelinek wrote:
>
> > We would need to add some tags (I wouldn't bother with pre-GCC 5 era,
> > because that doesn't have single number version numbers in the branch
> > names), like:
> > for r in 10 9 8 7 6;
On Fri, 10 Jan 2020, Jakub Jelinek wrote:
> We would need to add some tags (I wouldn't bother with pre-GCC 5 era,
> because that doesn't have single number version numbers in the branch
> names), like:
> for r in 10 9 8 7 6; do
> git tag branchpoints/gcc-$r `git rev-list $(git merge-base origin/
On Fri, 10 Jan 2020, Siddhesh Poyarekar wrote:
> I spent some time thinking about this and while it's trivial to fix by
> disabling ifuncs for static glibc, I wanted a solution that wasn't such
> a big hammer. The other alternative I could think of is to have an
> exported alias (called __builtin
Hi!
As I said earlier, one thing I find useful in svn compared to git are
the monotonically increasing revision numbers that we at Red Hat e.g. use
in our gcc bisect seed but I find it useful even in bugzilla everyday use.
With the help of various folks on IRC, I have something that seems to work
Hello,
Ref: https://bugs.linaro.org/show_bug.cgi?id=5479
Statically built independent programs that implement their own program
entry points (i.e. -ffreestanding -nostartfiles) and call __builtin_*
functions break when the builtin function in question is implemented as
an IFUNC in glibc and the b
On Thu, 9 Jan 2020, Joseph Myers wrote:
> Concretely, these are the changes I'm currently using to configure the
> hooks in a way I think appropriate for GCC, and it would be useful if the
> hooks could support such configuration in a more generic way in future so
> that we can stop using a GCC
> On Jan 10, 2020, at 6:15 PM, Joseph Myers wrote:
>
> On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
>
>> To me this looks like cherry-picks of r182541 and r182547 from
>> redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.
>
> r182541 is the first commit on /branches/redhat/gcc-4_7-branch after it
Bernd Schmidt :
> I was on the fence for a long time, since I felt that the rewritten
> reposurgeon was still somewhat unproven.
And that was a fair criticism for a short while, until the first compare-all
verification on the GCC history came back clean.
The most difficult point in the whole proc
mits so could be done while the git repository is
> still read-only for checking).
This gcc-10-20200110 snapshot is now available.
--
Joseph S. Myers
jos...@codesourcery.com
Snapshot gcc-10-20200110 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20200110/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
On Fri, 10 Jan 2020, Maxim Kuvyrkov wrote:
> To me this looks like cherry-picks of r182541 and r182547 from
> redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.
r182541 is the first commit on /branches/redhat/gcc-4_7-branch after it
was created as a copy of trunk. I.e., merging and cherry-picki
> On Jan 10, 2020, at 10:33 AM, Maxim Kuvyrkov
> wrote:
>
>> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
>> wrote:
>>
>> On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
>>> As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
>>> UTC on Saturday, I inte
On 1/9/20 5:28 AM, Eric S. Raymond wrote:
> I have been able to rescue or reconstruct from patches the following
> prehisoric GCC releases
Great job. This is important
>
> gcc-0.9
> gcc-1.21
> gcc-1.22
> gcc-1.25
> gcc-1.26
> gcc-1.27
> gcc-1.28
> gcc-1.35
>
> gcc-1.36
> gcc-1.37.1
> gcc-1.38
> gcc
On 1/10/20 1:53 PM, Nathan Sidwell wrote:
On 1/10/20 6:38 AM, Richard Biener wrote:
So I don't see any clear dissent and most folks just want to get this
done.
Just to chime in I also just want to get it done (well, I can handle
SVN as well :P).
I trust Joseph, too, but then from my POV anyth
On Fri, 10 Jan 2020 at 13:06, Joseph Myers wrote:
>
> On Fri, 10 Jan 2020, Jonathan Wakely wrote:
>
> > Could you avoid the double negative here? And the error message could
> > be more specific to the actual error by testing the two cases
> > separately, e.g.
>
> I'm sort of hoping we don't end u
On 1/10/20 8:33 AM, Maxim Kuvyrkov wrote:
Joseph, please point to message on gcc@ mailing list that expresses consensus
of GCC community to use reposurgeon conversion. Otherwise, it is not
appropriate to substitute one's opinion for community consensus.
I was on the fence for a long time, si
On Fri, 10 Jan 2020, Iain Sandoe wrote:
> One minor nit (and accepted that this might be too late).
Hooks can always be changed after the conversion is live.
> mail commit messages like this:
> [gcc-reposurgeon-8(refs/users/jsm28/heads/test-branch)] Test git hooks
> interaction with Bugzilla.
>
On Fri, 10 Jan 2020, Jonathan Wakely wrote:
> Could you avoid the double negative here? And the error message could
> be more specific to the actual error by testing the two cases
> separately, e.g.
I'm sort of hoping we don't end up using the hooks in this form for very
long - the patch was pos
On 1/10/20 6:38 AM, Richard Biener wrote:
So I don't see any clear dissent and most folks just want to get this
done.
Just to chime in I also just want to get it done (well, I can handle
SVN as well :P).
I trust Joseph, too, but then from my POV anything not worse than the current
mirror works
Richard Biener wrote:
On Fri, Jan 10, 2020 at 10:49 AM Richard Earnshaw (lists)
wrote:
On 10/01/2020 07:33, Maxim Kuvyrkov wrote:
On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
wrote:
On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
As noted on overseers, once Saturday's DAT
On Fri, Jan 10, 2020 at 10:49 AM Richard Earnshaw (lists)
wrote:
>
> On 10/01/2020 07:33, Maxim Kuvyrkov wrote:
> >> On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
> >> wrote:
> >>
> >> On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
> >>> As noted on overseers, once Saturday's DAT
On Fri, Jan 10, 2020 at 1:55 AM Gary Oblock wrote:
>
> This is at LTO time and the function in question is this:
>
> #include "stdlib.h"
> typedef struct bogus type_ta;
>
> struct bogus {
> int i;
> double x;
> int j;
> };
>
> void
> helper( void *x)
> {
> type_ta *y = (type_ta*)x;
> y->
On Thu, 9 Jan 2020 at 22:07, Joseph Myers wrote:
>
> @@ -63,6 +63,8 @@ class BranchUpdate(AbstractUpdate):
> # the update unless we have had a chance to verify that these hooks
> # work well with those branches.
> assert (self.ref_name.startswith('refs/heads/')
> +
On Thu, Jan 9, 2020 at 9:36 PM Gary Oblock wrote:
>
> Richard,
>
> Alas, when doing structure reorg I have to be able to know some
> arbitrary use of variable X in some GIMPLE expression is of a
> type that needs to be transformed in that given expression. I see no
> way around this.
Sure, if you
On 10/01/2020 07:33, Maxim Kuvyrkov wrote:
On Jan 9, 2020, at 5:38 AM, Segher Boessenkool
wrote:
On Wed, Jan 08, 2020 at 11:34:32PM +, Joseph Myers wrote:
As noted on overseers, once Saturday's DATESTAMP update has run at 00:16
UTC on Saturday, I intend to add a README.MOVED_TO_GIT file o
49 matches
Mail list logo
