Re: Enforcing order of execution for function arguments

Actually, I was thinking about the case "g(a(), b());". Let's imagine the gimplified code (because of your change) looks like: t1 = a(); t2 = b(); g(t1, t2); Are we always sure that t1 and t2 will not be pushed again in the CALL_EXPR by further transformations? No, and that's a good thing. W

Re: GPU-aware compiling?

Do you think - theoretically - that a compiler could help compiling software, which would in turn use the power of the GPU to make some of the computations? Theoretically -- yes. Of course. But... Like now we have compiler options like "-mmmx -msse -msse2 -msse3 -m3dnow" - would it be possibl

Re: typo in french error message

There is a typo in french translation of error messages (at least in 4.0 release and in 4.1 snapshot of 05/05/15). It affects gcc/po/fr.po and libcpp/po/fr.po : "sasn effet" should be "sans effet" "sasn lien" should be "sans lien" (The word "sasn" does not exist in french language). Yep. But tra

Re: preprocessor/21250 and address of

Opinions on how to handle this bug? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250 a) don't print the line; or b) output its line number as 1; or c) fix its line number (internally) as 1. c) seems cleanest to me, but I don't really care. This is especially an issue for people who use cpp to pre

Re: typo in french error message

http://www.iro.umontreal.ca/translation The link above gives a 404 error here. Do you have one that works? So sorry. The correct link of course is http://www.iro.umontreal.ca/translation/ (note the trailing slash). Segher

Re: Ada front-end depends on signed overflow

There's also a fair amount of code whih relies on -1 == (int)0x. Or is there any truly portable and efficient way to convert a sequence of bytes (in big-endian order) to a signed integer? Of course there is. Assuming no padding bits: int conv(unsigned char *c) { unsigned int

Re: Ada front-end depends on signed overflow

Better use a union for the (final) conversion, i.e int conv(unsigned char *c) { unsigned int i; union { unsigned int u; int i; } u; u.u = 0; for (i = 0; i < sizeof u; i++) u.u = (u.u << 8) + c[i]; return u.i; } This is not portable, though; access

Re: GCC-4.0.2 20050811: should GCC consider inlining functions in between different sections?

The question is in fact: what is a section for GCC? Is it just a way to group functions together to improve memory cache efficiency; or is the GCC user authorised to use sections to forbid access to some functions at link time? For user-declared ("attribute") sections, GCC just outputs the

Re: Inlining vs the stack

It could still be done, even if we inline. There is nothing that prevents us from adding space to the stack allocation only at that point, it's just not coded in gcc to do that. ...and take the stack alloc back after the inlined call is finished. This is what the original example needs; it doesn

Re: [PATCH]: kill HOST_PTR_PRINTF

| Beyond the "-Werror would have barfed" rationale, I have more evidence | that %p works everywhere we host GCC. If you look at the sources, | there are already a few uses of %p that have snuck in. So if it was a | problem we would have known by now. | | Do we assert for any other C90 feature

Re: [PowerPC] PR23774 stack backchain broken saga

On 10 sep 2005, at 02:03, Richard Henderson wrote: On Sat, Sep 10, 2005 at 01:00:04AM +0930, Alan Modra wrote: 2) Next, I defined parallels to keep things together. Like the following, with another for DImode. This seems most reasonable to me. Especially as the ABI states that the write o

Re: [PowerPC] PR23774 stack backchain broken saga

Especially as the ABI states that the write of the backlink and the stack pointer update _have_ to be done in one insn. That's on allocation. Deallocation isn't so critical. You just need to ensure the backchain is written before updating sp. Yes, but your example generated code showed all

Re: fwprop patch testing

int f(int *); int verbosity; int *arr; int last; void g () { int i; if (last < 4000) { if (verbosity >= 4) f(&verbosity); for (i = 0; i <= last; i++) arr[i] = i; } } If last != 0, arr+i cannot point to last for any i, as last is not part

Re: Silly GIT related question

On Wed, Jan 15, 2020 at 03:11:13AM +, Gary Oblock wrote: > If you just do a clone and don't checkout a branch, is this equivalent > the top of the trunk in the old scheme? If not then how do I get the > top of trunk? After doing the clone, run "git status" to see where you're at. Always run

Re: gcc-cvs mails for personal/vendor branches for merge commits

On Wed, Jan 15, 2020 at 04:37:49PM +, Iain Sandoe wrote: > I’m guessing that public development branches will probably gravitate to the > no non-FF mode, if they are to be used by people other than the primary author > > .. although that does somewhat limit things; rebasing WIP onto trunk and

Re: gcc-cvs mails for personal/vendor branches for merge commits

[ Please do reply to me when you reply to my mails. Maybe gmane did that? Yet Another reason not to use gmane. ] On Sat, Jan 18, 2020 at 11:04:12PM +0100, Julien _FrnchFrgg_ Rivaud wrote: > Le 18/01/2020 à 18:49, Segher Boessenkool a écrit : > >If a branch does rebase all people who

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

Hi! Thanks for doing this. On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: > This patch proposes some new (additional) rules for email subject lines > when contributing to GCC. The goal is to make sure that, as far as > possible, the subject for a patch will form a good

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

On Wed, Jan 22, 2020 at 10:00:00AM +, Richard Earnshaw (lists) wrote: > On 21/01/2020 19:26, Segher Boessenkool wrote: > >On Tue, Jan 21, 2020 at 02:52:00PM +, Richard Earnshaw (lists) wrote: > >>+ A brief summary > > > >You could stress that this is the

Re: [musl] musl, glibc and ideal place for __stack_chk_fail_local

On Sat, Jan 25, 2020 at 10:54:24AM -0500, Rich Felker wrote: > > To support smash stack protection gcc emits __stack_chk_fail > > calls on all targets. On top of that gcc emits __stack_chk_fail_local > > calls at least on i386 and powerpc: (Only on 32-bit -fPIC -msecure-plt, for Power). > There i

Re: [musl] musl, glibc and ideal place for __stack_chk_fail_local

On Thu, Jan 30, 2020 at 08:37:40AM -0500, Rich Felker wrote: > On Thu, Jan 30, 2020 at 06:33:51AM -0600, Segher Boessenkool wrote: > > On Sat, Jan 25, 2020 at 10:54:24AM -0500, Rich Felker wrote: > > > > To support smash stack protection gcc emits __stack_chk_fail > > &

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 02:54:05PM +0300, Alexander Monakov wrote: > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > > I've not seen any follow-up to this version. Should we go ahead and adopt > > this? > > Can we please go with 'committed' (lowercase) rather than all-caps COMMITTED? > S

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote: > On 03/02/2020 13:54, Segher Boessenkool wrote: > >None of this are *rules*. We should not pretend they are. An email > >subject should be useful to what the receivers of that email use it for: &g

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote: > On 03/02/2020 13:54, Segher Boessenkool wrote: > >None of this are *rules*. We should not pretend they are. An email > >subject should be useful to what the receivers of that email use it for: &g

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 01:59:58PM +, Richard Earnshaw (lists) wrote: > I think the linux rule (the whole line, not including the parts that are > removed on commit, should not exceed 75 characters) is far more sensible > - which is why this draft states this. FWIW, on a slightly older kerne

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 06:54:05PM +0100, Jakub Jelinek wrote: > On Mon, Feb 03, 2020 at 05:48:57PM +, Michael Matz wrote: > > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > > > > The idea is that the [...] part is NOT part of the commit, only part of > > > the email. > > > > I unde

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Feb 03, 2020 at 06:20:20PM +, Michael Matz wrote: > On Mon, 3 Feb 2020, Richard Earnshaw (lists) wrote: > > Well, I'd review a patch differently depending on whether or not it was > > already committed, a patch requiring review or an RFC looking for more > > general comments, so I *do

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Mon, Feb 03, 2020 at 01:24:04PM -0700, Jeff Law wrote: > ANd yes, even though I have been a regular ChangeLog user, I rely more > and more on the git log these days. As a reviewer, the changelog is priceless still. We shouldn't drop the changelog before people write *good* commit messages (and

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Thu, Feb 06, 2020 at 08:51:42AM +, Richard Sandiford wrote: > Segher Boessenkool writes: > > On Mon, Feb 03, 2020 at 01:24:04PM -0700, Jeff Law wrote: > >> ANd yes, even though I have been a regular ChangeLog user, I rely more > >> and more on the git log these

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Wed, Feb 05, 2020 at 06:43:54PM -0700, Jeff Law wrote: > On Wed, 2020-02-05 at 15:18 -0600, Segher Boessenkool wrote: > > As a reviewer, the changelog is priceless still. We shouldn't drop the > > changelog before people write *good* commit messages (and we are still >

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Thu, Feb 06, 2020 at 03:56:40PM +0100, Jakub Jelinek wrote: > On Wed, Feb 05, 2020 at 06:43:54PM -0700, Jeff Law wrote: > > And FWIW, we're talking about the ChangeLog *file* here. If folks > > continued writing the same log messages and put them into git, I > > personally think that's sufficie

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Thu, Feb 06, 2020 at 03:01:20PM +0100, Richard Biener wrote: > On Thu, Feb 6, 2020 at 2:51 PM Segher Boessenkool > wrote: > > If you rebase changelog files, then yes, it's a bloody pain ;-) > > So do you have a script that takes a commit with a ChangeLog at its

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Thu, Feb 06, 2020 at 01:57:49PM -0500, Jason Merrill wrote: > On Thu, Feb 6, 2020 at 11:25 AM Segher Boessenkool < > seg...@kernel.crashing.org> wrote: > > > > > We also need a way to fix changelog entries for the errors that do seep > > through (and that

Re: Git ChangeLog policy for GCC Testsuite inquiry

Hi! On Fri, Feb 07, 2020 at 10:19:56AM +0100, Richard Biener wrote: > On Thu, Feb 6, 2020 at 11:25 PM Segher Boessenkool > wrote: > > Yeah, don't look at me then :-) > > > > I *like* having most of those steps, most of this should only be done by > > p

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote: > On 07/02/2020 13:48, Segher Boessenkool wrote: > >Should we require some simple markup in the commit message before the > >changelogs? Maybe > > > >CL gcc/ > > * b

Re: Matching and testing against smulhsm3

Hi! On Fri, Feb 07, 2020 at 03:41:25PM +0100, m wrote: > ...so I tried to write a corresponding matching pattern, like so: > >   (define_insn "smulhshi3" >     [(set (match_operand:HI 0 "register_operand" "=r") >   (truncate:HI >     (ashiftrt:SI >   (mult:SI >     (sign_e

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Fri, Feb 07, 2020 at 03:43:05PM +, Richard Earnshaw (lists) wrote: > On 07/02/2020 15:32, Segher Boessenkool wrote: > >On Fri, Feb 07, 2020 at 01:56:08PM +, Richard Earnshaw (lists) wrote: > >>Any script should, in addition to extracting the author and email als

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Fri, Feb 07, 2020 at 03:34:03PM -0700, Tom Tromey wrote: > > "Jason" == Jason Merrill writes: > > Jason> I omit ChangeLogs by adding ':!*/ChangeLog' to the end of the git > Jason> send-email command. I don't remember where I found that incantation. > > Cool, I did not know about this. Y

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Sat, Feb 08, 2020 at 09:46:53AM +1030, Alan Modra wrote: > On Fri, Feb 07, 2020 at 10:08:25AM +, Jonathan Wakely wrote: > > With Git you can't really have unwanted local commits present in a > > tree if you use a sensible workflow, so if you tested in a tree that > > was at commit 1234abcd a

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Sat, Feb 08, 2020 at 03:55:33PM -0800, Andrew Pinski wrote: > On Sat, Feb 8, 2020 at 8:51 AM Segher Boessenkool > wrote: > > > > On Fri, Feb 07, 2020 at 03:34:03PM -0700, Tom Tromey wrote: > > > >>>>> "Jason" == Jason Merrill wr

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Sun, Feb 09, 2020 at 10:46:04AM +, Jonathan Wakely wrote: > My main point was that Richi should be committing things, not working > with uncommitted patches hanging around making things dirty. > > I like to use branches, but having a single branch with a series of > commits that you reorder

Re: Matching and testing against smulhsm3

On Sun, Feb 09, 2020 at 12:15:03PM +0100, m wrote: > On 2020-02-07 16:44, Segher Boessenkool wrote: > >>   (define_insn "smulhshi3" > >>     [(set (match_operand:HI 0 "register_operand" "=r") > >>   (truncate:HI > >>    

Re: Git ChangeLog policy for GCC Testsuite inquiry

On Mon, Feb 10, 2020 at 05:51:10PM +, Matthew Malcomson wrote: > Just for anyone interested -- the manpage that describes the '!' is > `gitglossary`. > > It's under the description of `pathspec`, and has a long-form of > `:(exclude)`. https://github.com/git/git/commit/93dbefb389a011c9107a39

Re: [EXTERNAL] Re: GCC selftest improvements

Hi! On Thu, Feb 13, 2020 at 10:18:27PM +, Modi Mo via gcc wrote: > Segher here suggests 4.8.5 instead of 4.8.2: > https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html I said as long as 4.8.5 works, it is fine with me. If 4.8.2 can be made to work easily that is useful for the few people who wou

Re: Matching and testing against smulhsm3

Hi! On Sun, Feb 16, 2020 at 09:52:12PM +0100, Marcus Geelnard wrote: >   (define_insn "smulhshi3" >     [(set (match_operand:HI 0 "register_operand" "=r") >   (truncate:HI >     (ashiftrt:SI >   (mult:SI >     (sign_extend:SI (match_operand:HI

Re: Matching and testing against smulhsm3

Hi! On Mon, Feb 17, 2020 at 09:54:58PM +0100, Marcus Geelnard wrote: > On 2020-02-17 02:12, Segher Boessenkool wrote: > >>Trying 10, 9 -> 11: > >>Failed to match this instruction: > >>(set (reg:SI 84) > >> (mult:SI (sign_extend:SI (subreg:HI (r

Re: [PATCH, v3] wwwdocs: e-mail subject lines for contributions

On Mon, Mar 02, 2020 at 01:01:46PM +, Richard Earnshaw (lists) wrote: > I'd like to. But have we reached consensus? Seems that every time I > produce a revised version of the text we end up in another round of bike > shedding. (Is that a word?) It's called a "lap", but "criterium" would b

Re: Fw: GSoC topic: Implement hot cold splitting at GIMPLE IR level

Hi! On Tue, Mar 03, 2020 at 10:25:32PM +0100, Jan Hubicka wrote: > I think this is bit stronger to what llvm does currently which relies on > outlining SESE regions earlier rather than going through the pain of > implementing support for partitioning. OTOH outlining can result in improved code,

Re: GCC 8.5 Status Report (2020-03-04)

On Wed, Mar 04, 2020 at 01:45:25PM +, Jonathan Wakely wrote: > On Wed, 4 Mar 2020 at 13:02, Jakub Jelinek wrote: > > The test says: > > // nl_NL chosen because it has no thousands separator (at this time). > > locale loc_it = locale(ISO_8859(15,nl_NL)); > > so no wonder that it FAILs if nl_

Re: How do I run SIMD Testcases on PPC64?

On Thu, Mar 05, 2020 at 05:04:16PM +, GT wrote: > At the top of that file is dejagnu directive: > /* { dg-require-effective-target vect_int } */ > > 1. How do I check to see if vect_int is defined? I suspect it as the reason > the test isn't run. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gc

Re: GSOC

Hi! On Sun, Mar 15, 2020 at 06:49:32PM +0530, shivam tiwari via Gcc wrote: > In Which Format I have to Send Gsoc Proposal On this Mail PDF or DOC Format On this email list, use plain text. Please read , the "Application" section there in particular, in this

Re: Not usable email content encoding

On Mon, Mar 16, 2020 at 04:54:51PM +0300, Alexander Monakov via Gcc wrote: > On Mon, 16 Mar 2020, Martin Liška wrote: > > > It's probably related to the following email tag: > > Content-Transfer-Encoding: quoted-printable > > > > The format is problematic when copying a patch. > > Email example:

Re: Not usable email content encoding

Hi! On Tue, Mar 17, 2020 at 03:51:58PM -0400, Frank Ch. Eigler via Gcc wrote: > > > Are you trying to copy from the raw message representation? > > > > Everyone trying to work with a patch (instead of just the email) always > > is working with the raw message. Just patch < mbox or git-am mbox

Re: Not usable email content encoding

Hi! On Wed, Mar 18, 2020 at 06:33:08PM -0400, Frank Ch. Eigler wrote: > > [...] We need to think about setting up easier ways for people to > > submit patches, rather than trying to fix all of the MUAs and MTAs > > in the world. > > Another related point. We are comingling email as a communicat

Re: Not usable email content encoding

Hi! On Wed, Mar 18, 2020 at 02:52:14PM -0700, Jim Wilson wrote: > I'm one of the old timers that likes our current work flow, but even I > think that we are risking our future by staying with antiquated tools. It's not ancient tools, it is low-requirement generic tools, and everyone can use that

Re: Possible Bug in make_more_copies

Hi Nick, On Wed, Mar 18, 2020 at 08:56:11PM -0400, Nicholas Krause wrote: > I've not sure if I've misunderstanding something in the combine code but > in make_more_copies > for combine.c this seems very odd: > if (!(REG_P (dest) && !HARD_REGISTER_P (dest))) >     continue; > >     rtx src = SET_

Re: Not usable email content encoding

On Thu, Mar 19, 2020 at 02:41:05PM +0100, Richard Biener wrote: > I guess if anything we'd want something git-centric now like github > or gitlab pull requests & reviews. The only complication is approval > then which would still mean manual steps. Patch review would also not > be publicly visibl

Re: Not usable email content encoding

On Thu, Mar 19, 2020 at 02:58:55PM +0100, Florian Weimer wrote: > * Richard Biener: > > I guess if anything we'd want something git-centric now like github > > or gitlab pull requests & reviews. The only complication is approval > > then which would still mean manual steps. > > Gitlab has a “merg

Re: How to update .debug_frame CFA offset for function epilogues?

Hi Jozef, On Thu, Mar 26, 2020 at 12:33:38PM +, Jozef Lawrynowicz wrote: > In some cases, I can fix the CFA offset by marking these epilogue insns as > frame_related anyway, and adding reg notes which describe the stack pointer > operations. For some other epilogue insns, marking them frame_re

Re: Not usable email content encoding

Hi! On Mon, Apr 06, 2020 at 09:58:27PM +0100, Maciej W. Rozycki wrote: > On Wed, 18 Mar 2020, Frank Ch. Eigler via Gcc wrote: > > > Out of curiousity, is this rewriting you are talking about the cause for a > > > lot of mails showing up as "From: GCC List" rather than their real > > > senders? >

Re: Not usable email content encoding

Hi! On Wed, Apr 08, 2020 at 01:50:51PM +, Michael Matz wrote: > On Wed, 8 Apr 2020, Mark Wielaard wrote: > > Earlier versions of Mainman2 had some issues which might accidentally > > change some headers. But the latest fixes make this possible. It is how > > the FSF handles DMARC for various

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, an

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 > &g

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

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

Re: Not usable email content encoding

Hi! On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote: > >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. > > I disagree. I find them quite usef

Re: Not usable email content encoding

Hi! On Fri, Apr 24, 2020 at 10:01:20PM +0200, Martin Jambor wrote: > On Fri, Apr 24 2020, Segher Boessenkool wrote: > > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote: > >> >Of course, better would be to remove ChangeLogs entirely (including not > >&g

Re: Not usable email content encoding

On Fri, May 01, 2020 at 09:51:53AM -0600, Jeff Law wrote: > On Thu, 2020-04-23 at 15:14 -0600, Tom Tromey wrote: > > > > > > > "Segher" == Segher Boessenkool > > > > > > > writes: > > > > Segher> My point was that this

Re: Not usable email content encoding

On Fri, May 01, 2020 at 10:37:48PM +0200, Martin Jambor wrote: > On Fri, May 01 2020, Jeff Law wrote: > >> I also find writing them useful as it forces me to go through every > >> patch one last time before submitting it :-) If you spend some time > >> configuring your text editor and git, the boil

Re: [Inline assembly] thought on the memory

Hi! On Thu, Apr 30, 2020 at 02:48:18PM +0200, FRÉDÉRIC RECOULES wrote: > I am looking for some clarification about how are working the memory > operands, especially when the constraint allows memory only (eg. "m"). > Please note that in a lesser extent, I know (by looking the gcc sources) how >

Re: Stability of pipermail ml archive URLs

Hi! On Thu, May 07, 2020 at 11:48:18AM +0200, Thomas Schwinge wrote: > By the way, the public-inbox software > (), as recently mentioned in a > different thread discussing deficiencies of Mailman's Pipermail, also > does support this: >

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi! On Sat, May 09, 2020 at 02:58:11AM +0700, Arseny Solokha wrote: > over the course of two years that had passed since the deprecation of the > powerpcspe backend, and a year and a half since its removal from gcc, I've > still > been speaking out several times against immediate closing of Bugzi

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi, On Sat, May 09, 2020 at 08:39:36PM +0200, John Paul Adrian Glaubitz wrote: > On 5/9/20 12:31 PM, Arseny Solokha wrote: > > I'd also like to nominate the following two: > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52927 > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60158 > > > > wh

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi! On Sat, May 09, 2020 at 01:45:20PM +0700, Arseny Solokha wrote: > > LRA has been supported by the rs6000 port since 2013 (01b1efaa1439), > > and made the default (and only!) option in 2017 (7a5cbf29beb2). Ah, the > > latter was slightly after the split, I see. Did powerpcspe never work > > w

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Sat, May 09, 2020 at 09:31:55AM +0100, Jonathan Wakely wrote: > If the bug is still present in supported versions (like gcc-8 or > gcc-9) but will never be fixed (like SPE ones) they might as well be > closed now as WONTFIX. Suggesting anything else will happen to them is > misleading. Yeah, I

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

On Wed, May 13, 2020 at 01:42:37AM +0100, Maciej W. Rozycki wrote: > On Sat, 9 May 2020, Eric Botcazou wrote: > > > > Strangely, I failed to find any PR for e200, so maybe some unnoticed ones > > > are still lying around. > > > > I think that the e200 support was never contributed upstream. > >

Re: How to update .debug_frame CFA offset for function epilogues?

Hi! On Mon, May 25, 2020 at 06:20:49PM +0100, Jozef Lawrynowicz wrote: > On Tue, Mar 31, 2020 at 04:49:53PM -0500, Segher Boessenkool wrote: > > You need reg_notes for more than just the stack updates: importantly, > > also for the restores of any saved register. > >

Re: [IMPORTANT] ChangeLog related changes

On Tue, May 26, 2020 at 03:14:02PM +0200, Andreas Schwab wrote: > On Mai 26 2020, Martin Liška wrote: > > > subprocess.check_output('git show --name-only --pretty="" | ' > > 'grep ChangeLog | ' > > git show --name-only --pretty= -- '*ChangeLog*' Or even ju

Re: [RFC] Closing of all remaining Bugzilla PRs against powerpcspe

Hi Arseny, On Mon, Jun 01, 2020 at 10:38:16AM +0700, Arseny Solokha wrote: > > PRs from the second group were filed by me, so if there's consensus to > > close all > > of them, the ones from this second group I can close myself. I don't > > have the > > right permissions to m

Push to my private branches is disallowed

Hi! $ git push -n fsf To git+ssh://gcc.gnu.org/git/gcc.git + 1db88c6...71e5e35 cc0 -> refs/users/segher/heads/cc0 (forced update) $ git push fsf Counting objects: 664, done. Delta compression using up to 64 threads. Compressing objects: 100% (239/239), done. Writing objects: 100% (504/504), 87.7

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 06:28:39PM +0200, Richard Biener wrote: > On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool > wrote: > >Of course it is not a fast-forward. I rebase the branches I publish, > >what is the point of publishing them otherwise? This is so that peo

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 06:41:02PM +0200, Andreas Schwab wrote: > On Jun 15 2020, Segher Boessenkool wrote: > > > On Mon, Jun 15, 2020 at 06:28:39PM +0200, Richard Biener wrote: > >> On June 15, 2020 6:05:26 PM GMT+02:00, Segher Boessenkool > >> wrote: > >&

Re: Push to my private branches is disallowed

Hi Joseph, Thanks, good to hear things will get better. On Mon, Jun 15, 2020 at 05:19:13PM +, Joseph Myers wrote: > > It should never send email for user branches *at all*. > > I think sending email for all branches showing the development taking > place there (as opposed to commits that ar

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 10:47:48AM -0700, H.J. Lu wrote: > These are all the reasons why I don't use GCC repo for my personal > branches. Yeah, but I thought a lot of different GCC people might be interested in my "nuke CC0" patches, so putting it in the official repo seemed like a good idea, for

Re: Push to my private branches is disallowed

On Mon, Jun 15, 2020 at 09:17:43PM +0200, Richard Biener wrote: > On June 15, 2020 7:19:13 PM GMT+02:00, Joseph Myers > wrote: > >I don't know if deleting and then recreating a user branch (in separate > > > >pushes) avoids the limit (and the excess mails) in the case where a > >user > >branch i

Re: Push to my private branches is disallowed

Hi! On Tue, Jun 16, 2020 at 11:11:01AM +0200, Martin Jambor wrote: > On Mon, Jun 15 2020, Segher Boessenkool wrote: > > What. > > > > Of course it is not a fast-forward. I rebase the branches I publish, > > what is the point of publishing them otherwise? This is so

Re: Push to my private branches is disallowed

On Tue, Jun 16, 2020 at 02:54:13PM +, Joseph Myers wrote: > On Tue, 16 Jun 2020, Jonathan Wakely via Gcc wrote: > > > I see no harm in rebasing public branches as long as nobody expects > > otherwise. > > And by design you *can* rebase user and vendor branches (but not those in > other names

Re: Push to my private branches is disallowed

Hi! On Tue, Jun 16, 2020 at 02:09:37PM +0100, Jonathan Wakely wrote: > I see no harm in rebasing public branches as long as nobody expects > otherwise. A public branch on gcc.gnu.org under refs/heads that is > being pulled by unknown persons and used in unknown forks for unknown > purposes shouldn

Re: documentation of powerpc64{,le}-linux-gnu as primary platform

On Thu, Jul 09, 2020 at 08:18:56PM -0500, Bill Schmidt via Gcc wrote: > >>>No, I don't leave this alone. The little endian target is dropped in > >>GCC 9 and > >>>GCC 10. Is this really what you intended to do? > >>No, it's not dropped. Some people are being pedantic about the name, > >>which is

Re: Problem with 64-bit only compiler build

On Tue, Aug 11, 2020 at 08:01:55PM -0400, Paul Smith wrote: > This is a kind of esoteric problem, but all the more annoying for that. :-) > As usual I've built my own version of GCC, and then I check it into Git > so that all builds can use this one canonical compiler regardless of > operating sy

Re: Silly question about pass numbers

On Tue, Aug 11, 2020 at 08:27:29PM +, Gary Oblock via Gcc wrote: > For these two dump files: > > exe.ltrans0.ltrans.074i.cp > > and > > exe.ltrans0.ltrans.087i.structure-reorg > > doesn't the ".074i." mean that this dump was created > before the ".087i." dump? It means that the 074 pass is

Re: Silly question about pass numbers

Hi! On Wed, Aug 12, 2020 at 08:26:34PM +, Gary Oblock wrote: > The files are from the same run: > -rw-rw-r-- 1 gary gary 3855 Aug 12 12:49 exe.ltrans0.ltrans.074i.cp > -rw-rw-r-- 1 gary gary 16747 Aug 12 12:49 > exe.ltrans0.ltrans.087i.structure-reorg > > By the time .cp was created inlinin

Re: Clobber REG_CC only for some constraint alternatives?

Hi! On Fri, Aug 14, 2020 at 04:46:59PM +0530, Senthil Kumar Selvaraj via Gcc wrote: > I'm working on porting AVR to MODE_CC, I'm very happy to see people work on that. > (define_insn "*mov_insn_noclobber_flags" > [(set (match_operand:ALL1 0 "nonimmediate_operand" "=r,d ,q,r") > (ma

Re: Clobber REG_CC only for some constraint alternatives?

Hi! On Fri, Aug 14, 2020 at 05:47:02PM +, Pip Cet wrote: > On Fri, Aug 14, 2020 at 4:24 PM Segher Boessenkool > wrote: > > On Fri, Aug 14, 2020 at 04:46:59PM +0530, Senthil Kumar Selvaraj via Gcc > > wrote: > > > (define_insn "*mov_insn_noclobber_flags"

Re: Clobber REG_CC only for some constraint alternatives?

On Sat, Aug 15, 2020 at 10:18:27AM +, Pip Cet wrote: > > > What I'm currently doing is this: > > > > > > (define_split > > > [(set (match_operand 0 "nonimmediate_operand") > > > (match_operand 1 "nox_general_operand"))] > > > "reload_completed && mov_clobbers_cc (insn, operands)" > > >

Re: Clobber REG_CC only for some constraint alternatives?

Hi! On Sun, Aug 16, 2020 at 06:28:44PM +, Pip Cet wrote: > > > IIUC, the idea is that references to REG_CC, except for clobbers, are > > > only introduced in the post-reload split pass, so it cannot be live > > > before our define_split runs. Does that make sense? > > > > Yes, it does. It has

Re: PowerPC long double Mangling

Hi! On Wed, Sep 09, 2020 at 02:42:36PM +0100, Jonathan Wakely wrote: > On Fri, 7 Aug 2020 at 22:14, Michael Meissner wrote: > > But assuming we want compatibility with libraries like glibc and libstdc++, > > I > > think we will have to continue to use "g" for __ibm128. Yes. > > With the long d

Re: PowerPC long double Mangling

On Wed, Sep 09, 2020 at 07:06:41PM +0200, Thomas Koenig wrote: > Am 09.09.20 um 17:36 schrieb Segher Boessenkool: > >You can use both __ibm128 and __ieee128 in one program, so it isn't an > >ABI change. Only the default of what "long double" means changes. And >

Re: PowerPC long double Mangling

On Wed, Sep 09, 2020 at 07:41:02PM +0200, Jakub Jelinek wrote: > On Wed, Sep 09, 2020 at 12:32:22PM -0500, Segher Boessenkool wrote: > > On Wed, Sep 09, 2020 at 07:06:41PM +0200, Thomas Koenig wrote: > > > Am 09.09.20 um 17:36 schrieb Segher Boessenkool: > > > >

Re: subreg vs vec_select

Hi Ilya, On Wed, Sep 09, 2020 at 11:50:56AM +0200, Ilya Leoshkevich via Gcc wrote: > I have a vector pseudo containing a single 128-bit value (V1TFmode) and > I need to access its last 64 bits (DFmode). Which of the two options > is better? > > (subreg:DF (reg:V1TF) 8) > > or > > (vec_select:DF

Re: A problem with one instruction multiple latencies and pipelines

Hi! On Mon, Sep 07, 2020 at 09:20:59PM +0100, Richard Sandiford wrote: > This is just personal opinion, but in general (from the point of view > of a new port, or a new subport like SVE), I think the best approach > to handling the "type" attribute is to start with the coarsest > classification th

  1   2   3   4   5   6   7   >