Re: Proposal for the transition timetable for the move to GIT

[Richard Earnshaw (lists)]

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 on SVN trunk
and change the SVN hooks to make SVN readonly, then disable gccadmin's
cron jobs that build snapshots and update online documentation until they
are ready to run with the git repository.  Once the existing git mirror
has picked up the last changes I'll make that read-only and disable that
cron job as well, and start the conversion process with a view to having
the converted repository in place this weekend (it could either be made
writable as soon as I think it's ready, or left read-only until people
have had time to do any final checks on Monday).  Before then, I'll work
on hooks, documentation and maintainer-scripts updates.


Where and when and by who was it decided to use this conversion?


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've gone back through this thread (if I've missed, or misrepresented, 
anybody who's expressed an opinion I apologize now).


Segher Boessenkool 
"If Joseph and Richard agree a candidate is good, then I will agree as
well.  All that can be left is nit-picking, and that is not worth it
anyway:"

Jeff Law 
"When Richard and I spoke we generally agreed that we felt a reposurgeon
conversion, if it could be made to work was the preferred solution,
followed by Maxim's approach and lastly the existing git-svn mirror."

Richard Earnshaw (lists) 
FWIW, I now support using reposurgeon for the final conversion.

And, of course, I'm taking Joseph's opinion as read :-)

So I don't see any clear dissent and most folks just want to get this 
done.



I want GCC community to get the best possible conversion, being it mine or 
reposurgeon's.  To this end I'm comparing the two conversions and will post my 
results later today.




Unfortunately, the comparison is complicated by the fact that you uploaded only "b" version of 
gcc-reposurgeon-8 repository, which uses modified branch layout (or confirm that there are no substantial 
differences between "7" and "8" reposurgeon conversions).


The main differences are

a) more revisions added due to commits upstream
b) release tags from SVN era now on the main release branch rather than 
in sidings
c) more author fixups from Joseph's cross validation against your 
repository and reposurgeon's own reports of suspect attributions



R.


--
Maxim Kuvyrkov
https://www.linaro.org

Re: [EXT] Re: Comparing types at LTO time

[Richard Biener]

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 view it as it transforming a type.  I see it as transforming
the layout of a specific object so all you need to know is whether an
arbitrary memory access accesses the very object - which you could,
if you face accesses you can't analyze, even check at runtime to some
extent (worst case by providing a copy in/out to a temporary with the
old layout).

Richard.

> 
> From: Richard Biener 
> Sent: Thursday, January 9, 2020 3:51 AM
> To: Jan Hubicka 
> Cc: Gary Oblock ; gcc@gcc.gnu.org 
> Subject: [EXT] Re: Comparing types at LTO time
>
> External Email
>
> --
> On Thu, Jan 9, 2020 at 9:53 AM Jan Hubicka  wrote:
> >
> > > There doesn't seem to be a way to compare types at LTO time. The functions
> > > same_type_p and comptypes are front end only if I'm not totally confused
> > > (which is quite possible) and type_hash_eq doesn't seem to apply for
> > > structure types. Please, any advice would be welcome.
> >
> > At LTO time it is bit hard to say what really is the "same type".  We
> > have multiple notions of equivalence:
> >  1) TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
> > means that both types were equal in tree merging at stream in, this
> > means that their IL representaiton is identical.
> >
> > This will lead to "false" for types that are same bud did not get
> > merged for various reasons. One such valid reason, for example, is
> > visibility of associated virtual tables
> >  2) types_types_same_for_odr returns true if types are considered same
> > by C++ one definition rule.  This is reliable but works only for C++
> > types with names (structures and unions)
> >  3) same_type_for_tbaa returns true if types are equivalent for type
> > based alias analysis.  It returns true in much more cases than 1
> > but is too coarse if you want to do datastructure changes.
> >
> > So in general this is quite hard problem (and in fact I started to play
> > with ODR types originally to understand it better).  I would suggest
> > starting with 1 if you want to rewrite types and eventually add a new
> > comparsion once pass does something useful.
> >
> > Richard may have some extra insights.
>
> My advice would be to not go down the route that requires comparing types
> since I'm not sure you can do that conservatively since you at the same
> time may not say two types are equal when they are not nor miss two
> equal types.  For example if you have a C TU and a Fortran TU there's
> defined interoperability but the actual type representations are distinct
> enough so that Honzas equality according to 1) doesn't trigger (nor does 2),
> but 3) does, but that will identify too many types as equal.
>
> Richard.
>
> > Honza
> > >
> > > Thanks,
> > >
> > > Gary Oblock
> > >

Re: GCC Git hooks

[Jonathan Wakely]

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/')
> +or self.ref_name.startswith('refs/users/')
> +or self.ref_name.startswith('refs/vendors/')
>  # Namespaces used by Gerrit.
>  or self.ref_name.startswith('refs/meta/')
>  or self.ref_name.startswith('refs/publish/')
> @@ -80,6 +82,20 @@ class BranchUpdate(AbstractUpdate):
>  # irrelevant.
>  if not is_null_rev(self.old_rev):
>  check_fast_forward(self.ref_name, self.old_rev, self.new_rev)
> +# GCC-specific: do not allow updates introducing ancestry
> +# based on the old git-svn repository, to ensure people
> +# rebase onto the new history rather than merging branches
> +# based on git-svn history into those based on the new history.
> +rev_list = git.rev_list(
> +self.new_rev, '^%s' % self.old_rev)
> +else:
> +rev_list = git.rev_list(
> +self.new_rev)
> +if '3cf0d8938a953ef13e57239613d42686f152b4fe' in rev_list:
> +raise InvalidUpdate(
> +'Refs not based on the git-svn history must not be '
> +'updated to be based on it, and new branches may not be '
> +'based on the old history.')

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.

if not is_null_rev(self.old_rev):
check_fast_forward(self.ref_name, self.old_rev, self.new_rev)
# GCC-specific: do not allow updates introducing ancestry
# based on the old git-svn repository, to ensure people
# rebase onto the new history rather than merging branches
# based on git-svn history into those based on the new history.
rev_list = git.rev_list(
self.new_rev, '^%s' % self.old_rev)
if '3cf0d8938a953ef13e57239613d42686f152b4fe' in rev_list:
raise InvalidUpdate(
'Refs must not be updated to introduce history from '
'the old git-svn repo.')
else:
rev_list = git.rev_list(
self.new_rev)
if '3cf0d8938a953ef13e57239613d42686f152b4fe' in rev_list:
raise InvalidUpdate(
'New branches must not be based on the old git-svn repo.')

Re: Anybody have any idea about why local_decls would go missing?

[Richard Biener]

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->i =  rand();
> }
>
> and I'm checking the local_decls it like this:
>
>   cgraph_node* node;
>   FOR_EACH_FUNCTION_WITH_GIMPLE_BODY ( node)
>   {
> tree decl;
> unsigned i;
>
> node->get_untransformed_body ();
>
> struct function *fn = DECL_STRUCT_FUNCTION ( node->decl);
> DEBUG( "L# %d, fuction name = %s\n", __LINE__, 
> lang_hooks.decl_printable_name ( node->decl, 2));
> if( fn == NULL )
> {
>   DEBUG( "  EMPTY\n");
>   continue;
> }
>
> FOR_EACH_LOCAL_DECL ( fn, i, decl)
> {
>   tree base = base_type_of ( decl);
>   DEBUG( "L# %d Consider local var decl\n", __LINE__);
>   .
>   .
>
> Needless to sat I get the function name "helper" but no variables.
> I suspected the LTO streaming process but that seems bullet proof
> and if local_decls are there when streaming out it should be restored when
> streaming in. I also suspected inlining but it still happened with
> "-fno-inline" present.
>
> If you'll note the get_untransformed_body call above (which David Malcolm
> suggested to cure a NULL fn) I suspect I'm lacking some other call
> which will make all things right.

If you look at the functions IL it might be there's only anonymous SSA
names left,
those are not visited by FOR_EACH_LOCAL_DECL.

Richard.

> Thanks,
>
> Gary Oblock
>
>
>

Re: Proposal for the transition timetable for the move to GIT

[Richard Biener]

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 DATESTAMP update has run at 00:16
> >>> UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN trunk
> >>> and change the SVN hooks to make SVN readonly, then disable gccadmin's
> >>> cron jobs that build snapshots and update online documentation until they
> >>> are ready to run with the git repository.  Once the existing git mirror
> >>> has picked up the last changes I'll make that read-only and disable that
> >>> cron job as well, and start the conversion process with a view to having
> >>> the converted repository in place this weekend (it could either be made
> >>> writable as soon as I think it's ready, or left read-only until people
> >>> have had time to do any final checks on Monday).  Before then, I'll work
> >>> on hooks, documentation and maintainer-scripts updates.
> >>
> >> Where and when and by who was it decided to use this conversion?
> >
> > 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've gone back through this thread (if I've missed, or misrepresented,
> anybody who's expressed an opinion I apologize now).
>
> Segher Boessenkool 
> "If Joseph and Richard agree a candidate is good, then I will agree as
> well.  All that can be left is nit-picking, and that is not worth it
> anyway:"
>
> Jeff Law 
> "When Richard and I spoke we generally agreed that we felt a reposurgeon
> conversion, if it could be made to work was the preferred solution,
> followed by Maxim's approach and lastly the existing git-svn mirror."
>
> Richard Earnshaw (lists) 
> FWIW, I now support using reposurgeon for the final conversion.
>
> And, of course, I'm taking Joseph's opinion as read :-)
>
> 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 for me.  Thanks to Maxim anyway for all the work - without that
we'd not switch in 10 other years...

Btw, "consensus" among the quiet doesn't usually work and "consensus" among
the most vocal isn't really "consensus".  I think GCC (and FOSS) works by
giving power to those who actually do the work.  Doesn't make it easier when
there are two, of course ;)

Richard.

Re: Proposal for the transition timetable for the move to GIT

[Iain Sandoe]

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 DATESTAMP update has run at  
00:16
UTC on Saturday, I intend to add a README.MOVED_TO_GIT file on SVN  
trunk

and change the SVN hooks to make SVN readonly, then disable gccadmin's
cron jobs that build snapshots and update online documentation until  
they

are ready to run with the git repository.  Once the existing git mirror
has picked up the last changes I'll make that read-only and disable  
that
cron job as well, and start the conversion process with a view to  
having

the converted repository in place this weekend (it could either be made
writable as soon as I think it's ready, or left read-only until people
have had time to do any final checks on Monday).  Before then, I'll  
work

on hooks, documentation and maintainer-scripts updates.


Where and when and by who was it decided to use this conversion?


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've gone back through this thread (if I've missed, or misrepresented,
anybody who's expressed an opinion I apologize now).

Segher Boessenkool 
"If Joseph and Richard agree a candidate is good, then I will agree as
well.  All that can be left is nit-picking, and that is not worth it
anyway:"

Jeff Law 
"When Richard and I spoke we generally agreed that we felt a reposurgeon
conversion, if it could be made to work was the preferred solution,
followed by Maxim's approach and lastly the existing git-svn mirror."

Richard Earnshaw (lists) 
FWIW, I now support using reposurgeon for the final conversion.

And, of course, I'm taking Joseph's opinion as read :-)

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 for me.  Thanks to Maxim anyway for all the work - without  
that

we'd not switch in 10 other years...

Btw, "consensus" among the quiet doesn't usually work and "consensus" among
the most vocal isn't really "consensus".  I think GCC (and FOSS) works by
giving power to those who actually do the work.  Doesn't make it easier  
when

there are two, of course ;)


Thanks to all those who’ve put (a lot of) effort into doing this work and  
those who’ve
challenged and tested the conversions, for my part, I am also happy to take  
Joseph’s

recommendation.

One minor nit (and accepted that this might be too late).

mail commit messages like this:
[gcc-reposurgeon-8(refs/users/jsm28/heads/test-branch)] Test git hooks  
interaction with Bugzilla.


seem to have a title stretched by redundant infomation ;
at least "users/jsm28/test-branch” would seem to contain all the necessary  
information


will commits in the user namespace appear on the mailing list in the end?

thanks again
Iain

Re: Proposal for the transition timetable for the move to GIT

[Nathan Sidwell]

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 for me.  Thanks to Maxim anyway for all the work - without that
we'd not switch in 10 other years...


Joseph's conversion please

nathan

--
Nathan Sidwell

Re: GCC Git hooks

[Joseph Myers]

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 posted to demonstrate the features that seem to need 
changes to the hook code, but hopefully that code can get extended 
upstream to support such features in a cleaner way and then we'll only 
need some custom configuration, not custom code.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Proposal for the transition timetable for the move to GIT

[Joseph Myers]

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.
> 
> seem to have a title stretched by redundant infomation ;
> at least "users/jsm28/test-branch” would seem to contain all the necessary
> information

I guess this is something to consider for any cleaner upstream support in 
the hooks for custom branch namespaces.

> will commits in the user namespace appear on the mailing list in the end?

Right now the configuration is for all commits to appear on the mailing 
list, just as all SVN commits do.  I think user namespace commits are 
interesting to see, but we can set hooks.no-emails to refs/users/ in the 
hook configuration if we don't want them to appear on the list - that 
configuration option already exists.  https://github.com/AdaCore/git-hooks 
documents the available configuration options.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Proposal for the transition timetable for the move to GIT

[Bernd Schmidt]

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, since I felt that the rewritten 
reposurgeon was still somewhat unproven. However, I think the 
reposurgeon conversion is probably the best choice at this point, given 
that an actual problem caused by the use of git-svn was demonstrated by 
Richard E, indicating that the scripts do not have an inherent 
reliability advantage. I also think Joseph has a very throrough pair of 
eyeballs.


I have no opinion one way or another which method should be used to 
identify author names, since I have not looked into that.



Bernd

Re: GCC Git hooks

[Jonathan Wakely]

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 up using the hooks in this form for very
> long - the patch was posted to demonstrate the features that seem to need
> changes to the hook code, but hopefully that code can get extended
> upstream to support such features in a cleaner way and then we'll only
> need some custom configuration, not custom code.

Gotcha. Forget what I said then.

Re: Proposal for the transition timetable for the move to GIT

[Martin Liška]

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 anything not worse than the current
mirror works for me.  Thanks to Maxim anyway for all the work - without that
we'd not switch in 10 other years...


Joseph's conversion please


+ 1

I would like to thank to all people involved in the GIT conversion!

Martin



nathan

Re: Rescue of prehistoric GCC versions

[Patrick Horgan via gcc]

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-1.39
> gcc-1.40
> gcc-1.41
> gcc-1.42
> gcc-2.1
> gcc-2.2.2
> gcc-2.3.3
> gcc-2.4.5
> gcc-2.5.8
> gcc-2.6.3
> gcc-2.7.2
> gcc-2.8.0
>
> The gap in the sequence represents the beginning of the repository
> history; r3 = gcc-1.36.
>
> The 0.9 to 0.35 tarballs can be glued to the front of the
> history, one commit each, with a firewall commit containing a deleteall
> to keep the content from leaking forward.  This is an issue because
> the early parts of the repo don't have complete trees.
>
> I'm now testing a conversion on the Great Beast that puts these in
> place. If all goes well I will push this capability to the public
> conversion repository later today.
>
> You can audit the reconstruction process by reading the script I wrote
> to automate it:
>
> https://gitlab.com/esr/gcc-conversion/blob/master/ancients
>
> Unfortunately, I was only able to find valid patch chains to three
> releases that don't have complete tarballs.
>
> If anyone else can scrounge up materials that could help complete
> the fossil sequence, now would be a really good time for that.  We
> have only three days at most left to integrate them.

Re: Proposal for the transition timetable for the move to GIT

[Maxim Kuvyrkov]

> 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 intend to add a README.MOVED_TO_GIT file on SVN trunk 
>>> and change the SVN hooks to make SVN readonly, then disable gccadmin's 
>>> cron jobs that build snapshots and update online documentation until they 
>>> are ready to run with the git repository.  Once the existing git mirror 
>>> has picked up the last changes I'll make that read-only and disable that 
>>> cron job as well, and start the conversion process with a view to having 
>>> the converted repository in place this weekend (it could either be made 
>>> writable as soon as I think it's ready, or left read-only until people 
>>> have had time to do any final checks on Monday).  Before then, I'll work 
>>> on hooks, documentation and maintainer-scripts updates.
>> 
>> Where and when and by who was it decided to use this conversion?
> 
> 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 want GCC community to get the best possible conversion, being it mine or 
> reposurgeon's.  To this end I'm comparing the two conversions and will post 
> my results later today.
> 
> Unfortunately, the comparison is complicated by the fact that you uploaded 
> only "b" version of gcc-reposurgeon-8 repository, which uses modified branch 
> layout (or confirm that there are no substantial differences between "7" and 
> "8" reposurgeon conversions).

There are plenty of difference between reposurgeon and svn-git conversions; 
today I've ignored subjective differences like author and committer entries and 
focused on comparing histories of branches.

Redhat's branches are among the most complicated and below analysis is 
difficult to follow.  It took me most of today to untangle it.  Let's look at 
redhat/gcc-9-branch.

TL;DR:
1. Reposurgeon conversion has extra history (more commits than intended) of 
redhat/gcc-4_7-branch@182541 merged into redhat/gcc-4_8-branch, which is then 
propagated into all following branches including redhat/gcc-9-branch.
2. Svn-git conversion has redhat/gcc-4_8-branch with history corresponding to 
SVN history, with no less and no more commits.
3. Other branches are likely to have similar issues, I didn't check.
4. I consider history of reposurgeon conversion to be incorrect.
5. The only history artifact (extra merges in reparented branches/tags) of 
svn-git conversion has been fixed.
6. I can appreciate that GCC community is tired of this discussion and wants it 
to go away.

Analysis:
Commit histories for redhat/gcc-9-branch match up to history inherited from 
redhat/gcc-4_8-branch (yes, redhat's branch history goes into ancient 
branches).  So now we are looking at redhat/gcc-4_8-branch, and the two 
conversions have different commit histories for redhat/gcc-4_8-branch.  This is 
relevant because it shows up in current development branch.  The histories 
diverge at r194477:

r194477 | jakub | 2012-12-13 13:34:44 + (Thu, 13 Dec 2012) | 3 lines

svn merge -r182540:182541 
svn+ssh://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_7-branch
svn merge -r182546:182547 
svn+ssh://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_7-branch

Added: svn:mergeinfo
## -0,0 +0,4 ##
   Merged /branches/redhat/gcc-4_4-branch:r143377,143388,144574,144578,155228
   Merged /branches/redhat/gcc-4_5-branch:r161595
   Merged /branches/redhat/gcc-4_6-branch:r168425
   Merged /branches/redhat/gcc-4_7-branch:r182541,182547


To me this looks like cherry-picks of r182541 and r182547 from 
redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.

[1] Note that commit r182541 is itself a merge of redhat/gcc-4_6-branch@168425 
into redhat/gcc-4_7-branch and cherry-picks from the other branches.  It is an 
actual merge (not cherry-pick) from redhat/gcc-4_6-branch@168425 because 
r168425 is the only commit to redhat/gcc-4_6-branch@168425 not present on 
trunk.  The other branches had more commits to their histories, so they can't 
be represented as git merges.

Reposurgeon commit for r194477 (e601ffdd860b0deed6d7ce78da61e8964c287b0b) 
merges in commit for r182541 from redhat/gcc-4_7-branch bringing *full* history 
of redhat/gcc-4_7-branch into redhat/gcc-4_8-branch.

Svn-git commit for r194477 (98d65ca0b53332e7c9cb62dfe85936a0e71d077e) 
cherry-picks commits r182541 and r182547 from redhat/gcc-4_7-branch.  As part 
of cherry-picking commit r182541 svn-git conversion merges 
redhat/gcc-4_6-branch@168425 into re

Re: Proposal for the transition timetable for the move to GIT

[Joseph Myers]

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-picking it are 
indistinguishable, and it's entirely correct for reposurgeon to consider a 
commit merging it as a merge from r182541 (together with a cherry-pick of 
r182547).

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-10-20200110 is now available

[gccadmin]

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 revision 280115

You'll find:

 gcc-10-20200110.tar.xz   Complete GCC

  SHA256=c3b624be071362b9ce7292ae95d59810a9eb5a003f40cfd938a039859677424f
  SHA1=51874857c60b9d2dc9b6a75a0228e4c8acb5fff4

Diffs from 10-20200105 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-10
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Proposal for the transition timetable for the move to GIT

[Joseph Myers]

On Thu, 9 Jan 2020, Joseph Myers wrote:

> On Wed, 8 Jan 2020, Jeff Law 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 planning to run at least one 
> snapshot (for some branch) manually *after* the conversion to test the 
> conversion of the gcc_release script to use git (in snapshot mode that 
> doesn't make any commits 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

Re: Proposal for the transition timetable for the move to GIT

[Eric S. Raymond]

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 process for me was in late
November.  That was when I faced up to the fact that, while I had a
Subversion dump reader that was 95% good, (1) that 5% could
disqualify it for this complex a history, and (2) I wasn't going to
be able to solve that last 5% without tearing down most of the reader
and rebuilding it.

The problem was that I'd been patching the dump reader to fix edge
cases for too long, and the code had rigidified. Too many auxiliary
data structures with partially overlapping semabtics - I couldn't
change anything without breaking everything. Which is the universe's
way of telling you it's time for a rewrite.

Of course the risk was that I wouldn't get that rewrite done in time
for deadline. But I had two assets that mitigated the risk. One was
a couple of very sharp collaborators, Julien Rivaud and Daniel Brooks
(and later another, Edward Cree). The other was having a really good
test suite, and a well-established procedure for integrating new
tests that jsm and rearnshaw were able to use.

It was (as the Duke of Wellington famously said) a damned near-run
thing. With all those advantages, if I had waited even a week longer
to make the crucial scrap-and-rebuild decision, the new reader might
have landed too late.

There's a lesson in here somewhere. When I figure out what it is, I'll
put it in my next book.
-- 
http://www.catb.org/~esr/";>Eric S. Raymond

Re: Proposal for the transition timetable for the move to GIT

[Maxim Kuvyrkov]

> 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 
> was created as a copy of trunk.  I.e., merging and cherry-picking it are 
> indistinguishable, and it's entirely correct for reposurgeon to consider a 
> commit merging it as a merge from r182541 (together with a cherry-pick of 
> r182547).

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.

--
Maxim Kuvyrkov
https://www.linaro.org

Re: GCC Git hooks

[Joseph Myers]

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-specific patched installation of the hooks.  
> The following features are hardcoded that didn't seem to have a way to 
> configure them:

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/heads/ because 
their push configuration for user or vendor branches was wrong).

-- 
Joseph S. Myers
jos...@codesourcery.com

[RFC] builtin functions and `-ffreestanding -nostartfies` with static binaries

[Siddhesh Poyarekar]

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 builtin results in a glibc call instead of
some inline code.

This happens because the startup code where ifuncs are resolved never
gets executed (since glibc's startup code is never executed) and hence
the PLT jumps fail.  The bug report talks about this as an aarch64
problem but I've been able to reproduce the problem on x86_64 as well.
One just needs to make sure that the __builtin_foo call results in a
glibc call.

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_strlen for example instead of strlen)
of a default implementation of the builtin function in glibc that gcc
generates a call to if freestanding && nostartfiles && static.

Any thoughts or other ideas on how this could be implemented?

Thanks,
Siddhesh

GIT: Monotonically increasing trunk and release branch ids

[Jakub Jelinek]

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.

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-$(expr $r - 1))..origin/master | tail -1`
done
git tag branchpoints/gcc-5 `git rev-list $(git merge-base origin/master 
origin/releases/gcc-4.9)..origin/master | tail -1`
and aliases:
git config --local alias.descr \!"f() { git describe --all --match 
'branchpoints/gcc-[0-9]*' \${1-master} | sed -n 
's,^tags/branchpoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\1-\\2,p;s,^tags/branchpoints/gcc-\\([0-9]\\+\\)\$,r\\1-0,p';
 }; f"
git config --local alias.undescr \!"f() { r=\$(echo \$1 | sed -n 
's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 
's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && 
exit 1; h=\$(git rev-parse --verify --quiet origin/releases/gcc-\$r); if test 
-z \$h; then h=\$(git rev-parse --verify --quiet origin/master); fi; p=\$(git 
describe --all --match 'branchpoints/gcc-'\$r \$h | sed -n 
's,^tags/branchpoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\1,p;s,^tags/branchpoints/gcc-[0-9]\\+\$,0,p');
 git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"

Then e.g.
$ git descr origin/master
r10-5824
$ git undescr r10-5824
42950b74c9b103676f99dc9f1a27859e3f7be436
$ git rev-parse origin/master
42950b74c9b103676f99dc9f1a27859e3f7be436
$ git descr branchpoints/gcc-10
r10-0
$ git undescr r10-0
fb7c6bf5aba75edc0cd439e0f07af3757bbda973
$ git descr branchpoints/gcc-10~
r9-7160
$ git undescr r9-7160
a5bc16f3199c9aa43aec5af2c2839a1cd4bfce1e
$ git rev-parse branchpoints/gcc-10
fb7c6bf5aba75edc0cd439e0f07af3757bbda973
$ git rev-parse branchpoints/gcc-10~
a5bc16f3199c9aa43aec5af2c2839a1cd4bfce1e
$ git descr2 origin/releases/gcc-9
r9-8116
$ git undescr r9-8116
3de43a2189f1e74b73b024109b922d7279dc7658

I'm sorry for my limited git-fu, could those branchpoints
tags be something that is fetched by default (given they would be added only
once a year for each trunk commit after the branching, usually the
BASE-VER bumping to N+1.0.0)?

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 before or after the 
hash
in the body which also makes it into bugzilla?

Another thing, we right now have the useful https://gcc.gnu.org/rNN 
redirects.
For those (i.e. SVN revisions), do we want them to point to the read-only SVN 
repo
svnweb, or remap those to the gitweb?
Can we get similarly https://gcc.gnu.org/rNN- (for 1-2 decimal digits 
before - and 1-6
decimal digits after it) pointing to the gitweb using the git undescr and let
bugzilla turn those rNN- strings in the comments into URLs?

Yet another thing are git hashes.  For those, I'd be afraid that turning 
[0-9a-f]{7,}
into URLs might trigger too often, do we want to use some prefix, like g12345ab 
to
be https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=12345ab ?  If we'd add an 
prefix,
then we should also adjust the gcc-cvs mail content to use those prefixes in 
there.

Thoughts on this?

Jakub

Re: [RFC] builtin functions and `-ffreestanding -nostartfies` with static binaries

[Alexander Monakov]

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_strlen for example instead of strlen)
> of a default implementation of the builtin function in glibc that gcc
> generates a call to if freestanding && nostartfiles && static.

In the Linaro bugreport you mention,

> Basically, IFUNCs and freestanding don't mix.

but really any libc (Glibc included) and -nostartfiles don't mix: stdio
won't be initialized, TLS won't be setup, and pretty much all other
libc-internal datastructures won't be properly setup. Almost no libc functions
are callable, because for example if they try to access 'errno', they crash.

Looking at the opening comment of the failing kselftest source:

 * This program tries to be as small as possible itself, to
 * avoid perturbing the system memory utilization with its
 * own execution.  It also attempts to have as few dependencies
 * on kernel features as possible.
 *
 * It should be statically linked, with startup libs avoided.
 * It uses no library calls, and only the following 3 syscalls:
 *   sysinfo(), write(), and _exit()

so in fact allowing it to link with libc strlen would be contrary to its intent.
The fix is simple: add -nodefaultlibs next to -nostartfiles in its Makefile, and
write a trivial loop in place of __builtin_strlen.

Alexander

Re: GIT: Monotonically increasing trunk and release branch ids

[Joseph Myers]

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/master 
> origin/releases/gcc-$(expr $r - 1))..origin/master | tail -1`
> done
> git tag branchpoints/gcc-5 `git rev-list $(git merge-base origin/master 
> origin/releases/gcc-4.9)..origin/master | tail -1`

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.

> I'm sorry for my limited git-fu, could those branchpoints
> tags be something that is fetched by default (given they would be added only
> once a year for each trunk commit after the branching, usually the
> BASE-VER bumping to N+1.0.0)?

Any tag in refs/tags is fetched by default.

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).

> 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 before or after 
> the hash
> in the body which also makes it into bugzilla?

This seems like another thing that would need new features in the hooks to 
support configuring email subjects and contents like that.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GIT: Monotonically increasing trunk and release branch ids

[Jakub Jelinek]

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; do
> >   git tag branchpoints/gcc-$r `git rev-list $(git merge-base origin/master 
> > origin/releases/gcc-$(expr $r - 1))..origin/master | tail -1`
> > done
> > git tag branchpoints/gcc-5 `git rev-list $(git merge-base origin/master 
> > origin/releases/gcc-4.9)..origin/master | tail -1`
> 
> 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?

> > I'm sorry for my limited git-fu, could those branchpoints
> > tags be something that is fetched by default (given they would be added only
> > once a year for each trunk commit after the branching, usually the
> > BASE-VER bumping to N+1.0.0)?
> 
> Any tag in refs/tags is fetched by default.
> 
> 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?
We'll need to tweak maintainer-scripts/gcc_release in any case.

> > 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 before or after 
> > the hash
> > in the body which also makes it into bugzilla?
> 
> This seems like another thing that would need new features in the hooks to 
> support configuring email subjects and contents like that.

Are the git hooks we use shared with AdaCore or GDB or where they come from
and can't be customized?

Jakub

Re: GCC Git hooks

[Joel Brobecker]

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:
> 
> > Looking at the configuration file, I believe the git-hooks
> > should have most, if not all, of the features that would be needed for
> > the GCC repository. In particular, there is already a way to relay
> > commits to third-party tools via calling of a script; GDB uses that
> > to interface with their Bugzilla database.
> 
> I am now looking at the hook setup for GCC.  As far as I can see, I'll 
> initially need a GCC-specific fork of the hooks for two reasons:
> 
> * Custom ref naming.  The refs/vendors//{heads,tags} and 
> refs/users//{heads,tags} scheme described at 
> , to avoid such branches 
> being fetched by default, will need the hooks to know that such ref names 
> are to be treated as branches / tags, and to allow non-fast-forward pushes 
> to them.

That's actually a neat way of dealing with vendor branches. I have
always felt it was suboptimal that everyone had to fetch updates
in vendor branches in the GDB repositories. I don't know if I could
convince the GDB community to use this scheme, but I think it's
pretty clever.

I'll make sure there is a way to handle that without needing to
create your own version of the git-hooks.

> * I don't see a configuration option to add custom checks before accepting 
> a ref update.  I think we want a custom check that prevents people for 
> accidentally pushing merges between the old and new versions of the GCC 
> history.  It's easy to write something called from a pre-receive / update 
> hook that uses git rev-list to identify problem pushes, but doing that 
> without a fork of the hooks would require a suitable configuration option 
> to call out to such a custom script.

I think an update-hook setting allowing repositories to have a script
called to perform additional ad hoc verifications sounds like it could
be generally useful.

For the specific issue that you are trying to protect against, that's
unlikely to happen, IMO. When someone pushes a commit, what the hooks
do is look at the list of commits which are being added to that branch.
If the number of such commits exceed a limit (100 by default), it
rejects that push. I think a user trying to push a merge that points
to the old history will hit that rejection.

I will add both of these features to my TODO list.

-- 
Joel

Re: GIT: Monotonically increasing trunk and release branch ids

[Joseph Myers]

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 better name to me.

> > 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 release tags is probably appropriate.

> > This seems like another thing that would need new features in the hooks to 
> > support configuring email subjects and contents like that.
> 
> Are the git hooks we use shared with AdaCore or GDB or where they come from
> and can't be customized?

Right now we have our own fork of the hooks in ~gccadmin/git-hooks.  I 
hope that appropriately generic versions of the GCC-specific features can 
be developed that mean we can stop using our own fork at some point and 
symlink to the version used by GDB instead.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC Git hooks

[Joel Brobecker]

> * 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/users and 
> refs/vendors in this case).

Once we add support for the update-hook, I think you'll be able to
implement that feature there.

This might be of general interest however, so I'll think about
something. Up until now, the configuration options taking patterns
have always taken pattern that activate the option of they match.
Here, we want "turn this option on, except in those cases".
Maybe the way to go is to have two options, both related:

  - allow-branch-deletion (default: True)
  - branch-deletion-exception (default: empty list)

The second option is ignored if allow-branch-deletion is True.

Project that want to reject them all, just sets the option to False.

Projects like GCC then use both:

  allow-branch-deletion: True
  branch-deletion-exception = 
  branch-deletion-exception = 

> * Controlling when non-fast-forward pushes are allowed for ref patterns 
> outside refs/heads.

OK.


-- 
Joel

Re: GCC Git hooks

[Joel Brobecker]

> > 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 the hooks.  
> > The following features are hardcoded that didn't seem to have a way to 
> > configure them:
> 
> 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/heads/ because 
> their push configuration for user or vendor branches was wrong).

I'm having a hard time understanding this requirement.

You want to say that, before branch "" gets created, you want
to verify that a branch named either "devel/" or "releases/"
does exist? And probably also that the commit in branch ""
is already present in the branch that already exists?

IIUC, I think this one is highly specialized, and shoud be done
in the update-hook script. Would that be OK?

-- 
Joel

Re: GIT: Monotonically increasing trunk and release branch ids

[Joel Brobecker]

> > 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-$(expr $r - 1))..origin/master | tail -1`
> > done
> > git tag branchpoints/gcc-5 `git rev-list $(git merge-base origin/master 
> > origin/releases/gcc-4.9)..origin/master | tail -1`
> 
> 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.
> 
> > I'm sorry for my limited git-fu, could those branchpoints
> > tags be something that is fetched by default (given they would be added only
> > once a year for each trunk commit after the branching, usually the
> > BASE-VER bumping to N+1.0.0)?
> 
> Any tag in refs/tags is fetched by default.
> 
> 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).

That's the default behavior, indeed. But the hooks can be configured
to allow lightweight tags. I personally would avoid them for tags
being pushed to a shared repository like GCC. Annotated tags provide
a lot more information.

> > 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 before or after 
> > the hash
> > in the body which also makes it into bugzilla?
> 
> This seems like another thing that would need new features in the
> hooks to support configuring email subjects and contents like that.

Can you describe a little more what you are looking for?

If you push a tag, this will trigger an email that looks like this:

| Subject: [repository_name] Created tag v0.1
| X-Act-Checkin: repository_name
| X-Git-Author: Test Suite 
| X-Git-Refname: refs/tags/v0.1
| X-Git-Oldrev: 
| X-Git-Newrev: c4c1e91cddc3d48a2aab7d454bc6537149f37dd8
|
| The unsigned tag 'v0.1' was created pointing to:
|
|  8b9a0d6... New file: a.
|
| Tagger: Joel Brobecker 
| Date: Tue Jun 26 07:51:14 2012 -0700
|
| This is a new tag.

Is that what we're discusing?

-- 
Joel

Re: GIT: Monotonically increasing trunk and release branch ids

[Joel Brobecker]

> > > 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 release tags is probably appropriate.

FWIW (with my GDB Release Manager hat, this time), some people have
asked about it shortly after GDB switched over to Git. I've been
signing them ever since.

-- 
Joel

Re: GIT: Monotonically increasing trunk and release branch ids

[Jakub Jelinek]

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 / -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 release tags is probably appropriate.
> 
> > > This seems like another thing that would need new features in the hooks 
> > > to 
> > > support configuring email subjects and contents like that.
> > 
> > Are the git hooks we use shared with AdaCore or GDB or where they come from
> > and can't be customized?
> 
> Right now we have our own fork of the hooks in ~gccadmin/git-hooks.  I 
> hope that appropriately generic versions of the GCC-specific features can 
> be developed that mean we can stop using our own fork at some point and 
> symlink to the version used by GDB instead.

Ok, could that stuff be customized based on branch and repository names, or
some knob in a configuration file?
I'll have a look at the hooks.

Jakub

Re: GCC Git hooks

[Joseph Myers]

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 accidentally push a branch into refs/heads/ because 
> > their push configuration for user or vendor branches was wrong).
> 
> I'm having a hard time understanding this requirement.
> 
> You want to say that, before branch "" gets created, you want
> to verify that a branch named either "devel/" or "releases/"
> does exist?

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 conventions mean that all 
branches in refs/heads/ should be called master, devel/something or 
releases/something.  But it's easy for someone to get a "git push" command 
wrong so that it would create a badly named branch.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC Git hooks

[Joel Brobecker]

> > > 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/heads/ because 
> > > their push configuration for user or vendor branches was wrong).
> > 
> > I'm having a hard time understanding this requirement.
> > 
> > You want to say that, before branch "" gets created, you want
> > to verify that a branch named either "devel/" or "releases/"
> > does exist?
> 
> 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 conventions mean that all 
> branches in refs/heads/ should be called master, devel/something or 
> releases/something.  But it's easy for someone to get a "git push" command 
> wrong so that it would create a badly named branch.

Could you rely on the update-hook script for that?

-- 
Joel

Re: GCC Git hooks

[Joseph Myers]

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 conventions mean that all 
> > branches in refs/heads/ should be called master, devel/something or 
> > releases/something.  But it's easy for someone to get a "git push" command 
> > wrong so that it would create a badly named branch.
> 
> Could you rely on the update-hook script for that?

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.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GCC Git hooks

[Joel Brobecker]

> 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 interacting between them, and
getting every one of them to behave the way people expect them
in all possible situations can quickly become a challenge.

I was concerned specifically with the interaction with the naming
scheme chosen for vendor and user branches, but I think we can make
it work:

   One config to list the naming scheme for branches
   One config to list the naming scheme for tags

I just want to be careful to also consider how all the options
are interacting with each other. In this case, we were able to
combine two requirements into one, so that addresses my concern.

-- 
Joel

Re: GIT: Monotonically increasing trunk and release branch ids

[Jakub Jelinek]

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 before or 
> > > after the hash
> > > in the body which also makes it into bugzilla?
> > 
> > This seems like another thing that would need new features in the
> > hooks to support configuring email subjects and contents like that.
> 
> Can you describe a little more what you are looking for?

So, the current SVN mails are like:
Subject: r280117 - in /trunk/libstdc++-v3: ChangeLog tes... 
   
To: gcc-...@gcc.gnu.org 
   

   
Author: redi
   
Date: Fri Jan 10 15:27:50 2020  
   
New Revision: 280117
   

   
URL: https://gcc.gnu.org/viewcvs?rev=280117&root=gcc&view=rev   
   
Log:
   
libstdc++: Fix testcase for C++98 compatibility 
   

   
* testsuite/25_algorithms/equal/deque_iterators/1.cc: Don't use C++11   
   
initialization syntax.  
   

   
Modified:   
   
trunk/libstdc++-v3/ChangeLog
   
trunk/libstdc++-v3/testsuite/25_algorithms/equal/deque_iterators/1.cc   
   

and the body is what is added into the bugzilla.
Now, looking at the git test mail, I see:
Subject: [gcc-reposurgeon-8] Test git hooks interaction with Bugzilla.  
   
To: gcc-...@gcc.gnu.org 
   

https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b


   
commit 3b2b821c3f1bac2ac6dd2481f461ec33a13eac9b 
   
Author: Joseph Myers   
   
Date:   Thu Jan 9 21:44:05 2020 +   
   

   
Test git hooks interaction with Bugzilla.   
   

   
PR c/93218  
   
* Test git hooks interaction with Bugzilla. 
   

Re: GIT: Monotonically increasing trunk and release branch ids

[Jason Merrill]

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 the help of various folks on IRC, I have something that seems to work.
>
> 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-$(expr $r - 1))..origin/master | tail -1`
> done
> git tag branchpoints/gcc-5 `git rev-list $(git merge-base origin/master 
> origin/releases/gcc-4.9)..origin/master | tail -1`
> and aliases:
> git config --local alias.descr \!"f() { git describe --all --match 
> 'branchpoints/gcc-[0-9]*' \${1-master} | sed -n 
> 's,^tags/branchpoints/gcc-\\([0-9]\\+\\)-\\([0-9]\\+\\)-g[0-9a-f]*\$,r\\1-\\2,p;s,^tags/branchpoints/gcc-\\([0-9]\\+\\)\$,r\\1-0,p';
>  }; f"
> git config --local alias.undescr \!"f() { r=\$(echo \$1 | sed -n 
> 's,^r\\([0-9]\\+\\)-[0-9]\\+\$,\\1,p'); n=\$(echo \$1 | sed -n 
> 's,^r[0-9]\\+-\\([0-9]\\+\\)\$,\\1,p'); test -z \$r && echo Invalid id \$1 && 
> exit 1; h=\$(git rev-parse --verify --quiet origin/releases/gcc-\$r); if test 
> -z \$h; then h=\$(git rev-parse --verify --quiet origin/master); fi; p=\$(git 
> describe --all --match 'branchpoints/gcc-'\$r \$h | sed -n 
> 's,^tags/branchpoints/gcc-[0-9]\\+-\\([0-9]\\+\\)-g[0-9a-f]*\$,\\1,p;s,^tags/branchpoints/gcc-[0-9]\\+\$,0,p');
>  git rev-parse --verify \$h~\$(expr \$p - \$n); }; f"
> Then e.g.
> $ git descr origin/master
> r10-5824
> $ git undescr r10-5824
> 42950b74c9b103676f99dc9f1a27859e3f7be436
> $ git rev-parse origin/master
> 42950b74c9b103676f99dc9f1a27859e3f7be436
> $ git descr branchpoints/gcc-10
> r10-0
> $ git undescr r10-0
> fb7c6bf5aba75edc0cd439e0f07af3757bbda973
> $ git descr branchpoints/gcc-10~
> r9-7160
> $ git undescr r9-7160
> a5bc16f3199c9aa43aec5af2c2839a1cd4bfce1e
> $ git rev-parse branchpoints/gcc-10
> fb7c6bf5aba75edc0cd439e0f07af3757bbda973
> $ git rev-parse branchpoints/gcc-10~
> a5bc16f3199c9aa43aec5af2c2839a1cd4bfce1e
> $ git descr2 origin/releases/gcc-9
> r9-8116
> $ git undescr r9-8116
> 3de43a2189f1e74b73b024109b922d7279dc7658

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 time to use in
naming your compiler binaries.

> I'm sorry for my limited git-fu, could those branchpoints
> tags be something that is fetched by default (given they would be added only
> once a year for each trunk commit after the branching, usually the
> BASE-VER bumping to N+1.0.0)?
>
> 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 before or after 
> the hash
> in the body which also makes it into bugzilla?
>
> Another thing, we right now have the useful https://gcc.gnu.org/rNN 
> redirects.
> For those (i.e. SVN revisions), do we want them to point to the read-only SVN 
> repo
> svnweb, or remap those to the gitweb?
> Can we get similarly https://gcc.gnu.org/rNN- (for 1-2 decimal digits 
> before - and 1-6
> decimal digits after it) pointing to the gitweb using the git undescr and let
> bugzilla turn those rNN- strings in the comments into URLs?
>
> Yet another thing are git hashes.  For those, I'd be afraid that turning 
> [0-9a-f]{7,}
> into URLs might trigger too often, do we want to use some prefix, like 
> g12345ab to
> be https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=12345ab ?  If we'd add an 
> prefix,
> then we should also adjust the gcc-cvs mail content to use those prefixes in 
> there.

At https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01211.html I
suggested the prefix "g:".

Jason

Re: GCC Git hooks

[Joseph Myers]

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 
commits made to git.  That feels like a reasonably generic check that 
might be reasonable to do in general without needing a configuration 
option, though I suppose it's only generic to repositories that have 
contributors who are used to GNU ChangeLog format.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: GIT: Monotonically increasing trunk and release branch ids

[Jakub Jelinek]

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 time to use in
> naming your compiler binaries.

In some spots, I think including both the rNN- and following -gN
would make a lot of sense, e.g. I think if that form went in the
commit mail body that is added into the bugzilla PRs.  Say
git describe --all --abbrev=40 --match 'branchpoints/gcc-[0-9]*' origin/master 
| sed 's,^tags/branchpoints/gcc-,r,'
r10-5824-g42950b74c9b103676f99dc9f1a27859e3f7be436
and let bugzilla and redirector handle that form and directly use
just the hash part of it for gitweb.  I think we should use for that
the 40 digit hashes, not just 7, there we'd risk they might not be unique
over time, right?
But e.g. for the commit mail subjects where space is precious, or I think
even for the bisect seed filenames, I think using just the part without
the hash when we have a way to get the hash back when needed is better.

> At https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01211.html I
> suggested the prefix "g:".

Ah, you suggested g: rather than just g.
We could then support
rN (1-6 decimal digits) - the svn revs, either for old repo, or transformed
g:X (X is any [0-9a-zA-Z_-], something else?, 1 or more chars) - gitweb 
with X
rNN-M (1-2 decimal digits, 1-6 decimal digits) - git undescr to hash
rNN-M-gX (perhaps limit X to hashes here, i.e. 7-40 hex digits) - 
gitweb with X
both in bugzilla and in the redirectors.

Jakub

Re: GIT: Monotonically increasing trunk and release branch ids

[Joseph Myers]

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 read-only), and commit (to master 
and GCC 9 and 8 branches) once we open up the converted repository for new 
commits.  It's likely however that there will be bugs in the parts of the 
code that are only used for releases but not snapshots, which will only 
show up when the first releases are built from git.

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-8-20200110 is now available

[gccadmin]

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-branch 
revision 280150

You'll find:

 gcc-8-20200110.tar.xzComplete GCC

  SHA256=4edbe3f3efbef3ae00196c07639ef7f4af6d2c82192388bc3f75b03b5aab4d15
  SHA1=5f11ed6f91717721b2a6ea287c37281c3174ce53

Diffs from 8-20200103 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [EXT] Re: Comparing types at LTO time

[Gary Oblock]

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 to fall back on.

If the struct reorg lumps all the types with the same shape together
into sets, aren't each of those sets type like and couldn't the sets be used
to drive the optimization?

Gary

From: Richard Biener 
Sent: Friday, January 10, 2020 2:29 AM
To: Gary Oblock 
Cc: Jan Hubicka ; gcc@gcc.gnu.org 
Subject: Re: [EXT] Re: Comparing types at LTO time

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 view it as it transforming a type.  I see it as transforming
the layout of a specific object so all you need to know is whether an
arbitrary memory access accesses the very object - which you could,
if you face accesses you can't analyze, even check at runtime to some
extent (worst case by providing a copy in/out to a temporary with the
old layout).

Richard.

> 
> From: Richard Biener 
> Sent: Thursday, January 9, 2020 3:51 AM
> To: Jan Hubicka 
> Cc: Gary Oblock ; gcc@gcc.gnu.org 
> Subject: [EXT] Re: Comparing types at LTO time
>
> External Email
>
> --
> On Thu, Jan 9, 2020 at 9:53 AM Jan Hubicka  wrote:
> >
> > > There doesn't seem to be a way to compare types at LTO time. The functions
> > > same_type_p and comptypes are front end only if I'm not totally confused
> > > (which is quite possible) and type_hash_eq doesn't seem to apply for
> > > structure types. Please, any advice would be welcome.
> >
> > At LTO time it is bit hard to say what really is the "same type".  We
> > have multiple notions of equivalence:
> >  1) TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2)
> > means that both types were equal in tree merging at stream in, this
> > means that their IL representaiton is identical.
> >
> > This will lead to "false" for types that are same bud did not get
> > merged for various reasons. One such valid reason, for example, is
> > visibility of associated virtual tables
> >  2) types_types_same_for_odr returns true if types are considered same
> > by C++ one definition rule.  This is reliable but works only for C++
> > types with names (structures and unions)
> >  3) same_type_for_tbaa returns true if types are equivalent for type
> > based alias analysis.  It returns true in much more cases than 1
> > but is too coarse if you want to do datastructure changes.
> >
> > So in general this is quite hard problem (and in fact I started to play
> > with ODR types originally to understand it better).  I would suggest
> > starting with 1 if you want to rewrite types and eventually add a new
> > comparsion once pass does something useful.
> >
> > Richard may have some extra insights.
>
> My advice would be to not go down the route that requires comparing types
> since I'm not sure you can do that conservatively since you at the same
> time may not say two types are equal when they are not nor miss two
> equal types.  For example if you have a C TU and a Fortran TU there's
> defined interoperability but the actual type representations are distinct
> enough so that Honzas equality according to 1) doesn't trigger (nor does 2),
> but 3) does, but that will identify too many types as equal.
>
> Richard.
>
> > Honza
> > >
> > > Thanks,
> > >
> > > Gary Oblock
> > >

git conversion in progress

[Joseph Myers]

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.

Assuming validation passes, I expect to make the converted repository 
available in place of the git-svn mirror (git://gcc.gnu.org/git/gcc.git 
and git+ssh://gcc.gnu.org/git/gcc.git) some time on Saturday.  That will 
be initially read-only to allow for people to review it in case any 
significant conversion issues are noticed late that would justify 
rerunning the conversion.  I propose to make it writable on Monday, at 
which point we'll be in development stage 4 for GCC 10 (and to leave 
gcc-reposurgeon-8.git around for a while in case people wish to use that, 
rather than the main repository, for any further testing, but to delete 
the older test conversions 1 through 7).  Some cron jobs may be re-enabled 
before then, subject to testing (I have git changes to gcc_release ready, 
for example, for testing snapshot generation), but the DATESTAMP updates 
won't be enabled until the repository is writable.

I encourage people to continue to work on improving the documentation for 
using git with GCC 
( and 
 list some of 
the things that it seems it might be useful to document).  Once the 
conversion is done we'll need to update various places referring to SVN on 
the website and in the manuals.

The old git-svn mirror will remain available read-only as 
git://gcc.gnu.org/git/gcc-old.git (which is already available), in 
addition to the refs from that mirror being in the new repository as 
refs/git-old/heads/*, refs/git-old/tags/* and refs/git-svn-old/heads/* 
(thus, gitweb links to commits in that repository will continue to work, 
as long as those commits were reachable as of when git mirror went 
read-only rather than having been on an old version of a branch that was 
since deleted or rebased).

Where people have active branches in that mirror, I hope they will rebase 
those branches onto the new version of the history, putting the results in 
refs/heads/devel/* or refs/users/*/heads/* according to whether they are 
considered generally shared development branches (can't have 
non-fast-forward pushes, should be documented on the GCC website) or user 
branches (can have non-fast-forward pushes, need not be documented).

-- 
Joseph S. Myers
jos...@codesourcery.com

Option processing question

[Gary Oblock]

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. Note, for an normal "-fbalh" 
there's
a flag_blah that I could look at but for this there seems to be zip, nil, 
diddly squat, etc.

Many thanks,

Gary

Re: [RFC] builtin functions and `-ffreestanding -nostartfies` with static binaries

[Siddhesh Poyarekar]

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 think of is to have an
>> exported alias (called __builtin_strlen for example instead of strlen)
>> of a default implementation of the builtin function in glibc that gcc
>> generates a call to if freestanding && nostartfiles && static.
> 
> In the Linaro bugreport you mention,
> 
>> Basically, IFUNCs and freestanding don't mix.
> 
> but really any libc (Glibc included) and -nostartfiles don't mix: stdio
> won't be initialized, TLS won't be setup, and pretty much all other
> libc-internal datastructures won't be properly setup. Almost no libc functions
> are callable, because for example if they try to access 'errno', they crash.
> 
> Looking at the opening comment of the failing kselftest source:
> 
>  * This program tries to be as small as possible itself, to
>  * avoid perturbing the system memory utilization with its
>  * own execution.  It also attempts to have as few dependencies
>  * on kernel features as possible.
>  *
>  * It should be statically linked, with startup libs avoided.
>  * It uses no library calls, and only the following 3 syscalls:
>  *   sysinfo(), write(), and _exit()
> 
> so in fact allowing it to link with libc strlen would be contrary to its 
> intent.
> The fix is simple: add -nodefaultlibs next to -nostartfiles in its Makefile, 
> and
> write a trivial loop in place of __builtin_strlen.

That's a valid point.  I'll recommend dropping __builtin_strlen from
that test.

Thanks,
Siddhesh

Re: Option processing question

[Prathamesh Kulkarni]

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 answer or even
> I good idea of where to look please let me know. Note, for an normal "-fbalh" 
> there's
> a flag_blah that I could look at but for this there seems to be zip, nil, 
> diddly squat, etc.
Hi,
Does checking flag_lto_partition == LTO_PARTITION_ONE work for your case ?

Thanks,
Prathamesh
>
> Many thanks,
>
> Gary

Re: Proposal for the transition timetable for the move to GIT

[Gerald Pfeifer]

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, even if
the other conversion was picked in the end.  Like others have said,
without that we would not be where we are now.

Thank you,
Gerald

Re: Proposal for the transition timetable for the move to GIT

[Gerald Pfeifer]

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 planning to run at least one 
> snapshot (for some branch) manually *after* the conversion to test the 
> conversion of the gcc_release script to use git (in snapshot mode that 
> doesn't make any commits so could be done while the git repository is 
> still read-only for checking).

Saturday's the GCC 9 snapshots are on, Sunday's GCC 10, so with a
GCC 10 snapshot out yesterday, perhaps run a GCC 9 snapshot today
or tomorrow and then fall back to the regular cadence?

Gerald