Re: scalar_storage_order question
On Wed, Apr 22, 2020 at 11:41 PM Eric Botcazou wrote:
>
> > What if we had this:
> > uint32_t u = 0x12345678;
> > upal_u32be_t tempb;
> > memcpy (&tempb, &u, sizeof(uint32_t));
> > uint32_t bu = tempb.val;
> >
> > Is that valid? We still run into the wrong code with the above case.
> > memcpy here should be considered a byte-by-byte copy and therefor
> > should not have any type punning except for to bytes.
>
> The usual trick of people doing type punning and pretending they don't. ;-)
> No, this cannot work as-is, although it's probably fixable by blocking the
> propagation through the memcpy in case the scalar order is flipped, unlike the
> previous example.
Yes the following is a decent workaround:
upal_u32be_t tempb;
memcpy (&tempb, &u, sizeof(uint32_t));
asm("":"+m"(tempb));
uint32_t bu = tempb.val;
But I wish this customer would not do this but they want it for some reason.
Thanks,
Andrew Pinski
>
> --
> Eric Botcazou
Re: scalar_storage_order question
> Yes the following is a decent workaround:
> upal_u32be_t tempb;
> memcpy (&tempb, &u, sizeof(uint32_t));
> asm("":"+m"(tempb));
> uint32_t bu = tempb.val;
OK, let me try to do the same in the compiler then.
--
Eric Botcazou
Re: Not usable email content encoding
On Thu, Apr 23, 2020 at 7:47 AM Florian Weimer wrote: > > * Tamar Christina: > > > A bit late to the party, but this really doesn't work that well > > because until recent version of gitlab there was no fairness > > guarantee. another patch could be approved after mine (with hours > > in between because of CI) and yet still get merged first causing my > > own patch to no longer apply, you'd rebase and roll the dice again. > > To fix this they added merge trains > > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ > > > > but trains for GCC Will likely be very short because of Changelog > > conflicts. So I don't think an automated merge workflow would work > > for projects where every single commit changes the same files. > > I had not thought about that. > > Does Gitlab support pluggable merge helpers? The gnulib changelog > auto-merger did a great job when we were still writing changelogs for > glibc. Btw, I encourage everybody trying to experiment with CI to set it up for release branches first because of the lower check-in count. Richard.
Re: Not usable email content encoding
On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote: > > * Tamar Christina: > > > A bit late to the party, but this really doesn't work that well > > because until recent version of gitlab there was no fairness > > guarantee. another patch could be approved after mine (with hours > > in between because of CI) and yet still get merged first causing my > > own patch to no longer apply, you'd rebase and roll the dice again. > > To fix this they added merge trains > > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ > > > > but trains for GCC Will likely be very short because of Changelog > > conflicts. So I don't think an automated merge workflow would work > > for projects where every single commit changes the same files. > > I had not thought about that. > > Does Gitlab support pluggable merge helpers? The gnulib changelog > auto-merger did a great job when we were still writing changelogs for > glibc. I've been having problems with it recently, e.g. https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog, because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog entry in the wrong place in gcc/testsuite/Changelog, as a result of a rebase using merge-changelog. Maybe we should follow glibc and get rid of ChangeLog files before trying to use automated CI and Git workflows.
Re: Not usable email content encoding
On Thu, Apr 23, 2020 at 09:34:20AM +0100, Jonathan Wakely via Gcc wrote: > I've been having problems with it recently, e.g. > https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog, > because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog > entry in the wrong place in gcc/testsuite/Changelog, as a result of a > rebase using merge-changelog. > > Maybe we should follow glibc and get rid of ChangeLog files before > trying to use automated CI and Git workflows. I thought we are leaning towards generating the ChangeLog files from commit messages rather than getting rid of them, but we need a reliable script to find the ChangeLog snippet in the commit message and split it into the separate ChangeLog files and reliable checker that will refuse commits with badly formatted entries in there, because when it comes from commit messages, we won't be able to fix mistakes in it later. Jakub
RE: Not usable email content encoding
> -Original Message- > From: Florian Weimer > > * Tamar Christina: > > > A bit late to the party, but this really doesn't work that well > > because until recent version of gitlab there was no fairness > > guarantee. another patch could be approved after mine (with hours in > > between because of CI) and yet still get merged first causing my own > > patch to no longer apply, you'd rebase and roll the dice again. > > To fix this they added merge trains > > > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_me > > rged_results/merge_trains/ > > > > but trains for GCC Will likely be very short because of Changelog > > conflicts. So I don't think an automated merge workflow would work > > for projects where every single commit changes the same files. > > I had not thought about that. > > Does Gitlab support pluggable merge helpers? The gnulib changelog auto- > merger did a great job when we were still writing changelogs for glibc. I'm not sure and couldn't find a clear answer from a look in the docs.. But I believe it's using git for the rebase so might be able to do it with githooks? It does have some built in conflicts resolution methods but with some surprising limitations: --- The file, with conflict markers added, is not over 200 KB in size --- And also --- Note: GitLab resolves conflicts by creating a merge commit in the source branch that is not automatically merged into the target branch. This allows the merge commit to be reviewed and tested before the changes are merged, preventing unintended changes entering the target branch without review or breaking the build. --- So you probably don't want it to be aware of the conflict.. Cheers, Tamar
blacklisted after announce on GNU cauldron ?
Hello, Since April 14 or so, I am not receiving any more messages from the gcc or gcc-patches mailing lists. This turns out to coincide with the date I sent to multiple lists the message announcing the unfortunate cancellation of the 2020 GNU Tools Cauldron. https://gcc.gnu.org/pipermail/gcc/2020-April/232119.html I'm sorry if that was wrong somehow. I understand we're supposed not to cross post in general. That didn't seem inappropriate in this particular case. A re-subscription attempt to the gcc mailing list just failed, expectedly I guess. I'd appreciate a suggestion on how I should proceed from there. Thanks in advance, Best Regards, Olivier
Re: blacklisted after announce on GNU cauldron ?
On 23/04/2020 11:09, Olivier Hainque wrote: > Hello, > > Since April 14 or so, I am not receiving any more messages > from the gcc or gcc-patches mailing lists. > > This turns out to coincide with the date I sent to multiple > lists the message announcing the unfortunate cancellation of > the 2020 GNU Tools Cauldron. > > https://gcc.gnu.org/pipermail/gcc/2020-April/232119.html > > I'm sorry if that was wrong somehow. I understand we're > supposed not to cross post in general. That didn't seem > inappropriate in this particular case. > > A re-subscription attempt to the gcc mailing list just > failed, expectedly I guess. > > I'd appreciate a suggestion on how I should proceed from > there. > > Thanks in advance, > > Best Regards, > > Olivier > One for the Overseers, I suspect. R.
[haifa-sched][restore_pattern] Can we recalculate INSN_TICK for the dependence type of REG_DEP_CONTROL？
Product: GCC
Component: rtl-optimization
Version: 7.3.0
If we add the flag DO_PREDICATION in scheduling ebb, the compiler will try to
predicate the insn when the producer insn has been issued,
and put the consumer insn into suitable queue. For example as shown in
schedule verbose dump file:
;; | insn | prio |
..
;; | 387 | 27 | t1=a5==0 AGS0|AGS1
;; | 388 | 27 | pc={(t1!=0)?L184:pc} PCU
;; | 459 | 26 | ev10=[a0+0xbc0]AGL0|AGL1
..
;;1--> + 387 t1=a5==0:AGS0|AGS1
deferring rescan insn with uid = 459.
;; dependencies resolved: insn + 459 predicated
;; Ready-->Q: insn + 459: queued for 2 cycles (change queue index)
;; tick updated: insn + 459 into queue with cost=2
insn 387 is a test insn, insn 388 is a jump insn, insn 459 is a load insn.
After predicating, insn 459 convert into this form: [!t1] ev10 = [a0+0xbc0]
and put insn 459 into queue[3]. INSN_TICK (459) = 3;
After issuing jump insn 388, the compiler will try to resotre pattern in insn
459 as shown in the following dump files.
;; Ready list after ready_sort: + 388:94:prio=27
;; Ready list (t = 1):+ 388:94:prio=27
[1;1]:388
;;1--> + 388 pc={(t1!=0)?L184:pc}:PCU
restoring pattern for insn 459
deferring rescan insn with uid = 459.
However, the INSN_TICK of insn 459 doesn't calculate again.
Actually, after restoring pattern, the insn can issue more earlier.
If we recalculate the INSN_TICK of insn 459, we will get INSN_TICK (459) = 2,
then the load insn 459 can issue at clock t = 2 instead of clock t = 3.
So, can we add the following code to recalculate the INSN_TICK in function
restore pattern?
restore_pattern (dep_t dep, bool immediately)
{
rtx_insn *next = DEP_CON (dep);
int tick = INSN_TICK (next);
.
if (DEP_TYPE (dep) == REG_DEP_CONTROL)
{
if (sched_verbose >= 5)
fprintf (sched_dump, "restoring pattern for insn %d\n",
INSN_UID (next));
haifa_change_pattern (next, ORIG_PAT (next));
+update_insn_after_change (next);
+if ((TODO_SPEC (next) & (HARD_DEP | DEP_POSTPONED)) == 0)
+ {
+fix_tick_ready (next);
+tick = INSN_TICK (next);
+ }
}
...
I found the similar code in function apply_replacement (dep_t dep, bool
immediately).
I think this patch can improve instruction parallelism.
Best wishes!
Re: Not usable email content encoding
Hi! On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote: > but trains for GCC Will likely be very short because of Changelog conflicts. Why that? Your patches should *not* touch changelog files, ever. For CI it is probably easiest if the CI never gets to see the changelog at all, and that isn't hard to do ;-) Segher
Re: Not usable email content encoding
On Thu, 23 Apr 2020 at 12:47, Segher Boessenkool wrote: > > Hi! > > On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote: > > but trains for GCC Will likely be very short because of Changelog conflicts. > > Why that? Your patches should *not* touch changelog files, ever. > > For CI it is probably easiest if the CI never gets to see the changelog > at all, and that isn't hard to do ;-) For the actual CI testing, yes. But if you want an automated "merge after CI testing passes" then what you merge needs to add a ChangeLog entry. So either we auto-generate the entry when doing the auto-merge, or the ChangeLog entry is already there.
Re: Not usable email content encoding
On Thu, Apr 23, 2020 at 12:56:20PM +0100, Jonathan Wakely wrote: > On Thu, 23 Apr 2020 at 12:47, Segher Boessenkool > wrote: > > On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote: > > > but trains for GCC Will likely be very short because of Changelog > > > conflicts. > > > > Why that? Your patches should *not* touch changelog files, ever. > > > > For CI it is probably easiest if the CI never gets to see the changelog > > at all, and that isn't hard to do ;-) > > For the actual CI testing, yes. But if you want an automated "merge > after CI testing passes" then what you merge needs to add a ChangeLog > entry. So either we auto-generate the entry when doing the auto-merge, > or the ChangeLog entry is already there. Why would we make it part of the patch for that? That is backwards :-) If it isn't part of the patch, no matter how we do it I don't see how it would cause conflicts? Segher
C-Vise project introduction
Hello. I would like to announce a new Python fork of the C-Reduce tool: https://github.com/marxin/cvise I'm going to start with a bit of history and motivation behind the project. All started 6 years ago when I joined SUSE as a toolchain developer and I quickly became a friend with C-Reduce that I've been using for reduction of the GCC compiler test-cases. No having enough numbers, but I claim I've used the tool probably one thousand times and I must be one the biggest users of the tool. I wanted to contribute to the project since then but I'm not much familiar with Perl language. There's a pending attempt of Moritz who rewrote the tool to Python language 4 year ago and he hasn't received a proper review. I feel the original authors don't like the language and when he announced a final comparable port (2 years ago) there was still no feedback. I took his work and now I'm offering the port to the community with the following improvements: 1) C-Vise is a super-parallel implementation where all passes run their transform and test script phase in parallel; that resolves #160; I've seen significant speed up on a 16-core Zen CPU 2) the project contains native BinaryState object which can help with fast traversal of a state space 3) Python is hopefully more popular language than Perl Minor improvements: - --log-level option - one can print different level of messages - --remove-pass - one can skip a pass in pass manager (#200, #202) - --list-passes - listing of existing passes (#150) - project contains unit tests for some passes - LLVM 9 and 10 support (#193, #204) - --clang-delta-std option - workaround for #210 - unifdef and delta subprojects are removed from the repository - --timing-since-start - print timestamps since the start of a reduction Known limitations: - configure & make build support is dropped - FreeBSD and Windows port is not tested - dependency on python-Pebble package - a small issue observed in Pebble (noxdafox/pebble#58) I'm planning to create a proper Github release soon and I've done an openSUSE package: https://build.opensuse.org/package/show/home:marxin:devel:tools/cvise I would like to thank the original authors and Moritz for the port. I'm planning to share the codebase of clang_delta (and clex) which is an essential part of each C/C++ test-case reduction process. Feel free to test the project and come up with a feedback. Martin
Re: AVR CC0 transition
> On Apr 22, 2020, at 10:11 PM, Senthil Kumar via Gcc wrote: > > On Wed, Apr 22, 2020 at 10:08 PM Jeff Law wrote: >> >> On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote: >>> Hi, >>> >>> I'm thinking about attempting to do the CC0 transition for the >>> AVR port in my spare time. I've read the CC0Transition gcc wiki >>> page, and as the AVR ISA does not have non-condition-code >>> clobbering arithmetic instructions, concluded that I'd have to >>> follow the steps outlined for case #2. >>> >>> Are there any other things I need to watch out for? >> Not offhand. You might want to look at how Bernd did the m68k though. I >> think a >> conceptually similar transition would be reasonable for AVR as well as the >> alternative would be dropping the AVR port. Last year I did the CC0 conversion for pdp11, which is another case #2 architecture, and a pretty simple one for the most part. I followed the Wiki fairly closely, with help from Eric. One thing that may not be relevant is that pdp11 has two CCREGS, one for float, one for integers. paul
Re: blacklisted after announce on GNU cauldron ?
Hi - > > A re-subscription attempt to the gcc mailing list just > > failed, expectedly I guess. I see no sign in the logs of Olivier being banned in any form. Please resubscribe online and forward complete failure symptoms if you believe this is still happening. - FChE
Re: `insn does not satisfy its constraints` when compiling a simple program.
Hi, thanks for the response, I've given debugging it a try but I cannot figure out what is causing it to fail. It's probably just my inexperience. Thanks for the input, it's very much appreciated. Cheers, Joe On 20/04/2020 19:43, Jim Wilson wrote: On Sat, Apr 18, 2020 at 8:45 AM Joe via Gcc wrote: test.c: In function ‘main’: test.c:5:1: error: insn does not satisfy its constraints: The constrain_operands function is failing to match the insn to its constraints. Try putting a breakpoint there, and stepping through the code to see what is going wrong. The function is likely called many times, so you might need to figure out which call is the failing one first and only step through that one. Jim
Re: blacklisted after announce on GNU cauldron ?
Hi Frank, > On 23 Apr 2020, at 16:34, Frank Ch. Eigler wrote: > > Hi - > >>> A re-subscription attempt to the gcc mailing list just >>> failed, expectedly I guess. > > I see no sign in the logs of Olivier being banned in any form. Please > resubscribe online and forward complete failure symptoms if you > believe this is still happening. Thanks for your feedback! I managed to subscribe again by going through the gcc list specific info page :-) My previous attempts were issued from https://gcc.gnu.org/lists.html#subscribe Subscribing from there doesn't work and leads to a page which provides instructions which don't work either. From there I thought the coincidence was troubling. There is actually a FAQ link on the instructions page, which I just checked, and ... it directs to a 404 page: https://sourceware.org/pipermail/index.html#faqs I'll try to re-subscribe to gcc-patches now. Thanks again! With Kind Regards, Olivier
Re: AVR CC0 transition
On Thu, 2020-04-23 at 07:41 +0530, Senthil Kumar wrote: > On Wed, Apr 22, 2020 at 10:08 PM Jeff Law wrote: > > On Wed, 2020-04-22 at 22:01 +0530, Senthil Kumar via Gcc wrote: > > > Hi, > > > > > > I'm thinking about attempting to do the CC0 transition for the > > > AVR port in my spare time. I've read the CC0Transition gcc wiki > > > page, and as the AVR ISA does not have non-condition-code > > > clobbering arithmetic instructions, concluded that I'd have to > > > follow the steps outlined for case #2. > > > > > > Are there any other things I need to watch out for? > > Not offhand. You might want to look at how Bernd did the m68k though. I > > think a > > conceptually similar transition would be reasonable for AVR as well as the > > alternative would be dropping the AVR port. > > Hi Jeff, > > Thanks, I will take a look at Bernd's work. IIRC, he took a > different approach from what was suggested in the wiki, right? Right. Conceptually he brought the cc0-setter insn back into the cc0-user insn, but kept some ability to remove the cc0-setter when the previous insn had set the condition codes in a useful way. Jeff >
Re: Not usable email content encoding
On Thu, 2020-04-23 at 09:34 +0100, Jonathan Wakely via Gcc wrote: > On Thu, 23 Apr 2020 at 06:49, Florian Weimer wrote: > > * Tamar Christina: > > > > > A bit late to the party, but this really doesn't work that well > > > because until recent version of gitlab there was no fairness > > > guarantee. another patch could be approved after mine (with hours > > > in between because of CI) and yet still get merged first causing my > > > own patch to no longer apply, you'd rebase and roll the dice again. > > > To fix this they added merge trains > > > https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/ > > > > > > but trains for GCC Will likely be very short because of Changelog > > > conflicts. So I don't think an automated merge workflow would work > > > for projects where every single commit changes the same files. > > > > I had not thought about that. > > > > Does Gitlab support pluggable merge helpers? The gnulib changelog > > auto-merger did a great job when we were still writing changelogs for > > glibc. > > I've been having problems with it recently, e.g. > https://gcc.gnu.org/g:e76100ced607218a3bf had to fix a changelog, > because https://gcc.gnu.org/g:d76925e46fad09fc9be67 put my changelog > entry in the wrong place in gcc/testsuite/Changelog, as a result of a > rebase using merge-changelog. > > Maybe we should follow glibc and get rid of ChangeLog files before > trying to use automated CI and Git workflows. This is precisely why I want to get rid of ChangeLogs and instead generate them from the VCS as part of the release process. Ultimately I want to be able to use workflows where I can push a button on something that's gone through a CI cycle or "git am" and not have to go back and fix things *by hand*. What we do with ChangeLogs is (*&@#$*)(*&^ insane from an efficient workflow standpoint. jeff
Re: Not usable email content encoding
On Thu, 2020-04-23 at 06:46 -0500, Segher Boessenkool wrote: > Hi! > > On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote: > > but trains for GCC Will likely be very short because of Changelog conflicts. > > Why that? Your patches should *not* touch changelog files, ever. > > For CI it is probably easiest if the CI never gets to see the changelog > at all, and that isn't hard to do ;-) *Nothing* should touch changelog files :-) They should be generated from the VCS. IMHO of course. That implies that the patch includes a proper ChangeLog entry in the commit message. It also implies that if we muck one up, then we live with it rather than going back and rewriting them. jeff
Re: Not usable email content encoding
It seems like this discussion doesn't have to be cc'ed to overseers. At the very least it doesn't need to be cc'ed *twice* as someone who apparently doesn't understand that gcc.gnu.org == sourceware.org has cc'ed overseers in both domains. So, I'd appreciate it if you all would please drop overseers from future replies in this thread. The overseers mailing list doesn't need to be involved in discussions on what gcc does with ChangeLogs. Please edit your cc list. Thank you.
Re: blacklisted after announce on GNU cauldron ?
On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote: >Hi Frank, > >> On 23 Apr 2020, at 16:34, Frank Ch. Eigler wrote: >> >> Hi - >> A re-subscription attempt to the gcc mailing list just failed, expectedly I guess. >> >> I see no sign in the logs of Olivier being banned in any form. Please >> resubscribe online and forward complete failure symptoms if you >> believe this is still happening. > >Thanks for your feedback! > >I managed to subscribe again by going through the gcc >list specific info page :-) > >My previous attempts were issued from > > https://gcc.gnu.org/lists.html#subscribe > >Subscribing from there doesn't work and leads >to a page which provides instructions which don't work >either. > >From there I thought the coincidence was troubling. > >There is actually a FAQ link on the instructions page, >which I just checked, and ... it directs to a 404 page: > > https://sourceware.org/pipermail/index.html#faqs > >I'll try to re-subscribe to gcc-patches now. All of the above is handled by whomever is responsible for the gcc web pages. It would be nice if someone fixed those links.
Re: Not usable email content encoding
Hi - > *Nothing* should touch changelog files :-) They should be generated from the > VCS. IMHO of course. IMHO: the VCS should be the changelog. - FChE
Re: blacklisted after announce on GNU cauldron ?
On Thu, 23 Apr 2020 at 16:46, Christopher Faylor via Gcc wrote: > > On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote: > >Hi Frank, > > > >> On 23 Apr 2020, at 16:34, Frank Ch. Eigler wrote: > >> > >> Hi - > >> > A re-subscription attempt to the gcc mailing list just > failed, expectedly I guess. > >> > >> I see no sign in the logs of Olivier being banned in any form. Please > >> resubscribe online and forward complete failure symptoms if you > >> believe this is still happening. > > > >Thanks for your feedback! > > > >I managed to subscribe again by going through the gcc > >list specific info page :-) > > > >My previous attempts were issued from > > > > https://gcc.gnu.org/lists.html#subscribe > > > >Subscribing from there doesn't work and leads > >to a page which provides instructions which don't work > >either. > > > >From there I thought the coincidence was troubling. > > > >There is actually a FAQ link on the instructions page, > >which I just checked, and ... it directs to a 404 page: > > > > https://sourceware.org/pipermail/index.html#faqs > > > >I'll try to re-subscribe to gcc-patches now. > > All of the above is handled by whomever is responsible for the > gcc web pages. It would be nice if someone fixed those links. Yes, removing the broken subcription form on gcc.gnu.org/lists.html is on my TODO list, but gcc-10 work is higher priority.
Re: blacklisted after announce on GNU cauldron ?
On Thu, 23 Apr 2020 at 18:02, Jonathan Wakely wrote: > > On Thu, 23 Apr 2020 at 16:46, Christopher Faylor via Gcc > wrote: > > > > On Thu, Apr 23, 2020 at 05:13:13PM +0200, Olivier Hainque wrote: > > >Hi Frank, > > > > > >> On 23 Apr 2020, at 16:34, Frank Ch. Eigler wrote: > > >> > > >> Hi - > > >> > > A re-subscription attempt to the gcc mailing list just > > failed, expectedly I guess. > > >> > > >> I see no sign in the logs of Olivier being banned in any form. Please > > >> resubscribe online and forward complete failure symptoms if you > > >> believe this is still happening. > > > > > >Thanks for your feedback! > > > > > >I managed to subscribe again by going through the gcc > > >list specific info page :-) > > > > > >My previous attempts were issued from > > > > > > https://gcc.gnu.org/lists.html#subscribe > > > > > >Subscribing from there doesn't work and leads > > >to a page which provides instructions which don't work > > >either. > > > > > >From there I thought the coincidence was troubling. > > > > > >There is actually a FAQ link on the instructions page, > > >which I just checked, and ... it directs to a 404 page: > > > > > > https://sourceware.org/pipermail/index.html#faqs > > > > > >I'll try to re-subscribe to gcc-patches now. > > > > All of the above is handled by whomever is responsible for the > > gcc web pages. It would be nice if someone fixed those links. > > Yes, removing the broken subcription form on gcc.gnu.org/lists.html is > on my TODO list, but gcc-10 work is higher priority. Patch submitted for approval now: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html
Re: blacklisted after announce on GNU cauldron ?
On Thu, Apr 23, 2020 at 06:39:54PM +0100, Jonathan Wakely wrote: >On Thu, 23 Apr 2020 at 18:02, Jonathan Wakely wrote: >>On Thu, 23 Apr 2020 at 16:46, Christopher Faylor wrote: >>>All of the above is handled by whomever is responsible for the gcc web >>>pages. It would be nice if someone fixed those links. >> >>Yes, removing the broken subcription form on gcc.gnu.org/lists.html is >>on my TODO list, but gcc-10 work is higher priority. > >Patch submitted for approval now: >https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544461.html Thanks! cgf
Re: Not usable email content encoding
On Thu, Apr 23, 2020 at 09:33:47AM -0600, Jeff Law wrote: > On Thu, 2020-04-23 at 06:46 -0500, Segher Boessenkool wrote: > > Hi! > > > > On Thu, Apr 23, 2020 at 12:54:04AM +, Tamar Christina wrote: > > > but trains for GCC Will likely be very short because of Changelog > > > conflicts. > > > > Why that? Your patches should *not* touch changelog files, ever. > > > > For CI it is probably easiest if the CI never gets to see the changelog > > at all, and that isn't hard to do ;-) > *Nothing* should touch changelog files :-) They should be generated from the > VCS. IMHO of course. My point was that this should *never* be part of patches, already. > That implies that the patch includes a proper ChangeLog entry in the commit > message. It also implies that if we muck one up, then we live with it rather > than going back and rewriting them. There also is the middle ground where we still have changelog files, but normal checkins automatically update those from the commit message. This is an intermediate step, but also makes it possible (and even easy) to fix up mistakes. Segher
Re: Not usable email content encoding
Hi! On Thu, Apr 23, 2020 at 12:57:43PM -0400, Frank Ch. Eigler wrote: > > *Nothing* should touch changelog files :-) They should be generated from > > the > > VCS. IMHO of course. > > IMHO: the VCS should be the changelog. The VCS shows what changed. The changelog shows what was meant to be changed. The difference is very helpful for reviewers, and for post-mortem purposes, etc. This can be more than compensated for if submitters would write better patch descriptions, of course. But will that happen? Segher
Re: Not usable email content encoding
> "Segher" == Segher Boessenkool writes: Segher> My point was that this should *never* be part of patches, already. FWIW, I use a few scripts so that I can keep ChangeLogs as files. That's what I do when working on gdb. https://github.com/tromey/git-gnu-changelog This is easier on the whole, IME, because it means there is no extra manual step before pushing. Of course, better would be to remove ChangeLogs entirely (including not putting anything like them into a commit message), because they are largely not useful and are just make-work. Again IMNSHO -- I know there are some folks who read them, but I basically never have since switching to git. Tom
