I am glad this email created some discussion.
Some users seem to think the change was either reckless or nontransparent.
This includes one user who replied me off list:
> Please continue until they tell the truth.
Given the additional context provided by the answers, I agree with that opinion.
I
> Quite a few projects under the GNU project[1] have dissociated
themselves from the FSF, so "as defined by the FSF" perhaps doesn't
apply as consistently as it did before.
That doesn't really answer any of my questions, though.
On 6/10/21 7:18 AM, Martin Liška wrote:
On 6/10/21 11:07 AM, Martin Liška wrote:
Doing that, one has 2 unique links, that would be needed for get_option_url function.
Plus, both :option:`-Wfoo` and :option:`-Wno-foo` references are going to work.
And I've actually did the transformation and
Snapshot gcc-9-20210610 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/9-20210610/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 9 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On 6/10/21 3:28 PM, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 03:16:43PM -0600, Martin Sebor wrote:
Just look at the start of this thread. Some people put
the [PRn] only in the first line of the commit. And that is
what these changes want to diagnose, that is an error and results
in bug
On Thu, Jun 10, 2021 at 03:16:43PM -0600, Martin Sebor wrote:
> > Just look at the start of this thread. Some people put
> > the [PRn] only in the first line of the commit. And that is
> > what these changes want to diagnose, that is an error and results
> > in bugzilla not being updated.
>
On 6/10/21 1:09 PM, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 12:55:43PM -0600, Martin Sebor wrote:
Instead of rejecting commits that don't mention all the same PRs on
the first line of the commit as in the ChangeLog entries it seems
that the Git commit script could extract the PR referen
On Thu, Jun 10, 2021 at 12:55:43PM -0600, Martin Sebor wrote:
> Instead of rejecting commits that don't mention all the same PRs on
> the first line of the commit as in the ChangeLog entries it seems
> that the Git commit script could extract the PR references from
> just the ChangeLong entries
On 6/10/21 11:30 AM, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 11:20:26AM -0600, Martin Sebor wrote:
One other note: you mention policy above, which suggests a requirement.
My understanding is that the format of a commit message is a convention
put in place to take some of the tedium out of c
On Thu, Jun 10, 2021 at 11:20:26AM -0600, Martin Sebor wrote:
> One other note: you mention policy above, which suggests a requirement.
> My understanding is that the format of a commit message is a convention
> put in place to take some of the tedium out of creating ChangeLog
> entries. If that's
On 6/10/21 11:06 AM, Martin Sebor wrote:
On 6/10/21 9:56 AM, Jonathan Wakely wrote:
On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote:
On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote:
On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wak
On 6/10/21 9:56 AM, Jonathan Wakely wrote:
On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote:
On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote:
On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote:
On 10/06/21 10:44 +010
On Thu, 10 Jun 2021, Martin Liška wrote:
> 1) Can we organize the new documentation in $gccroot/doc folder
> similarly to what I have in texi2rst-generated repo? Would be beneficial
> as we can have a single Makefile and shared content will be in a same
> depth to the individual manuals.
Where
On Thu, 10 Jun 2021 at 16:55, Tobias Burnus wrote:
> Independent of the PR matching and checking issues, I think Jonathan was
> thinking about extending the documentation (as I gathered from IRC
> #gcc);
Right.
> I did not quite follow whether it is about best practice or
> contained bits which
HI team
I am trying to use the gcc 11 docker hub image to build AMX code but it
fails
/usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h:
Assembler messages:
/usr/local/lib/gcc/x86_64-linux-gnu/11.1.0/include/amxtileintrin.h:42:
Error: no such instruction: `ldtilecfg (%rdi)'
/usr/
On Thu, 10 Jun 2021 at 15:56, Martin Sebor wrote:
>
> On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote:
> > On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote:
> >>
> >> On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote:
> >>> On 10/06/21 10:44 +0100, Jonathan Wakely wrote:
>
On 10.06.21 16:55, Martin Sebor via Gcc wrote:
I'm a little lost as to what's being changed, and, truth be told,
what exactly the current "right" format is. Where are the PRn
strings recognized as special?
For my version of the patch at least, which is
https://gcc.gnu.org/pipermail/gcc-pat
As part of the ranger development we have found that there are various
pieces of the infrastructure that can be used independently, and we’d
like to document them in the hopes that they are useful to others. We
will be contributing short posts documenting parts of the ranger, which
we hope can
On 6/10/21 4:40 AM, Jonathan Wakely via Gcc wrote:
On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote:
On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote:
On 10/06/21 10:44 +0100, Jonathan Wakely wrote:
Quite interesting idea! Are you willing to prepare a patch for it?
On 6/2/21 7:27 PM, Joseph Myers wrote:
On Mon, 31 May 2021, Martin Liška wrote:
https://splichal.eu/scripts/sphinx/
Looking at some examples there:
https://splichal.eu/scripts/sphinx/gcc/_build/html/c-implementation-defined-behavior/preprocessing-directives.html
has some conversion problems:
On 6/10/21 11:07 AM, Martin Liška wrote:
Doing that, one has 2 unique links, that would be needed for get_option_url
function.
Plus, both :option:`-Wfoo` and :option:`-Wno-foo` references are going to work.
And I've actually did the transformation and one can see it e.g. here:
https://splichal
As well as the "contrig" typo that Florian noticed, the subject says
"in in" which should be "is in". And it should be CC'd to gcc-patches.
I like this more than my attempt, however ...
>--- a/contrib/gcc-changelog/git_repository.py
>+++ b/contrib/gcc-changelog/git_repository.py
>@@ -59,8 +59,9 @
* Tobias Burnus:
> On 10.06.21 10:07, Martin Liška wrote:
>> On 6/10/21 8:35 AM, Tobias Burnus wrote:
>>> One options would be to require a 'PR /' line if there is
>>> 'PRn+' in the commit title, rejecting the commit otherwise.
>>
>> Quite interesting idea! Are you willing to prepare a patch f
On 10.06.21 10:07, Martin Liška wrote:
On 6/10/21 8:35 AM, Tobias Burnus wrote:
One options would be to require a 'PR /' line if there is
'PRn+' in the commit title, rejecting the commit otherwise.
Quite interesting idea! Are you willing to prepare a patch for it?
Done.
I was thinking o
On Thu, 10 Jun 2021 at 11:08, Jakub Jelinek wrote:
>
> On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote:
> > On 10/06/21 10:44 +0100, Jonathan Wakely wrote:
> > > > Quite interesting idea! Are you willing to prepare a patch for it?
> > >
> > > This works.
> >
> > And this wo
On 6/7/21 4:19 PM, Tobias Burnus wrote:
On 07.06.21 15:28, Martin Liška wrote:
* I note that we write before the argument index, that those are
without -/-- prefix
but that's not true. Something to fix after the conversation.
Can you please show me a few examples of it?
* https://splicha
On Thu, Jun 10, 2021 at 11:01:49AM +0100, Jonathan Wakely via Gcc wrote:
> On 10/06/21 10:44 +0100, Jonathan Wakely wrote:
> > > Quite interesting idea! Are you willing to prepare a patch for it?
> >
> > This works.
>
> And this works better, because it checks the PR in the title matches
> one in
On 10/06/21 10:44 +0100, Jonathan Wakely wrote:
Quite interesting idea! Are you willing to prepare a patch for it?
This works.
And this works better, because it checks the PR in the title matches
one in the changelog.
I'll get something added to the tests and prep this for commit.
diff --g
> Quite interesting idea! Are you willing to prepare a patch for it?
This works.
diff --git a/contrib/gcc-changelog/git_commit.py b/contrib/gcc-changelog/git_commit.py
index bd8c1ff7af2..58aad8b7f26 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -15
On 2021/6/10 11:31, Xionghu Luo via Gcc-patches wrote:
> Hi,
> I noticed that the "git gcc-commit-mklog" command doesn't extract PR
> number from title to ChangeLog automatically, then the committed patch
> doesn't update the related bugzilla PR website after check in the patch?
Well then you shou
On 6/4/21 5:10 PM, Martin Sebor wrote:
On 6/3/21 4:56 AM, Martin Liška wrote:
On 6/2/21 10:41 PM, Martin Sebor wrote:
On 5/31/21 7:25 AM, Martin Liška wrote:
Hello.
I've made quite some progress with the porting of the documentation and
I would like to present it to the community now:
https:/
On 6/10/21 8:35 AM, Tobias Burnus wrote:
On 10.06.21 08:17, Martin Liška wrote:
Yes, we currently only support automatic extraction from comments from
test-cases.
How does your commit title look like? Note that we require bugzilla
components
being part of PR entry, which is not commonly used in
On 6/10/21 8:25 AM, Xionghu Luo wrote:
On 2021/6/10 14:17, Martin Liška wrote:
On 6/10/21 7:22 AM, Xionghu Luo wrote:
Sorry, should be sent to this mail-list.
On 2021/6/10 11:31, Xionghu Luo via Gcc-patches wrote:
Hi,
I noticed that the "git gcc-commit-mklog" command doesn't extract PR
num
33 matches
Mail list logo