On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> wrote:
> >
> > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > I'm seeing compiler crashes building
Hi Richard,
On Fri, Dec 13, 2019 at 10:31:54PM +, Richard Sandiford wrote:
> >> I didn't say it was combine's fault that RA was bad. I said it was
> >> combine's fault that we have two pseudos rather than one.
See below.
> My point was the extra pseudo<-pseudo2 move is created by combine fo
Hi!
On Mon, Dec 16, 2019 at 03:13:49PM -0700, Jeff Law wrote:
> On Mon, 2019-12-16 at 15:59 -0600, Segher Boessenkool wrote:
> > In particular, we should look carefully at the commit
> > > attributions in both conversions and Maxim's may well give ideas for
> >
Hi,
On Mon, Dec 16, 2019 at 05:07:48PM +, Joseph Myers wrote:
> Yes. It should be possible to confirm branch tip conversions and other
> properties of the repository (e.g. that all branch tips are properly
> descended from the first commit on trunk except for the specific branches
> that s
have anything resembling
> reposurgeon's test suite.
So? Such a test suite does not magically prevent bugs (whatever type
it is: regressions, unit tests, whatever methodology).
The only thing that matters is acceptance testing (which includes such
trivial things ass "are all the file
On Mon, Dec 16, 2019 at 02:13:06PM +, Joseph Myers wrote:
> On Mon, 16 Dec 2019, Segher Boessenkool wrote:
>
> > Most of us are perfectly happy even with the current git mirror, for
> > old commits. We want "real" git to make the workflow for new commits
> &g
On Mon, Dec 16, 2019 at 08:54:51AM -0500, Eric S. Raymond wrote:
> Segher Boessenkool :
> > > Do people really want to keep tweaking the conversions and postpone the
> > > git switchover?
> >
> > No.
>
> It may not be my place to say, but...I think the stak
On Mon, Dec 16, 2019 at 01:43:48PM +0100, Mark Wielaard wrote:
> On Mon, 2019-12-16 at 11:29 +, Joseph Myers wrote:
> > On Mon, 16 Dec 2019, Mark Wielaard wrote:
> >
> > > Should we go with the gcc-reparent.git repo now?
> >
> > I think we should go with the reposurgeon conversion, with all R
Hi!
On Mon, Dec 16, 2019 at 10:53:05AM +0100, Mark Wielaard wrote:
> On Fri, 2019-12-06 at 17:44 +0300, Maxim Kuvyrkov wrote:
> > > On Sep 19, 2019, at 6:34 PM, Maxim Kuvyrkov
> > > wrote:
> > > > On Sep 17, 2019, at 3:02 PM, Richard Earnshaw (lists)
> > > > wrote:
> > > >
> > > > Monday 16th
On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> wrote:
> >
> > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > I'm seeing compiler crashes building
On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> I'm seeing compiler crashes building libgcc for powerpc64le-linux-gnu,
> cross-compiling from x86_64-pc-linux-gnu. I'm at SVN revision 279830.
> I'm seeing the following. Is anybody else seeing this crash? Thanks.
No, a
On Fri, Dec 13, 2019 at 04:22:11PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Fri, Dec 13, 2019 at 12:45:47PM +, Richard Sandiford wrote:
> >> combine's to blame for the fact that we have two pseudo registers rather
> >> than one. Se
On Fri, Dec 13, 2019 at 12:45:47PM +, Richard Sandiford wrote:
> combine's to blame for the fact that we have two pseudo registers rather
> than one. See the comments about the avr-elf results in:
>
>https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02150.html
>
> for more details.
It's not
On Thu, Dec 12, 2019 at 10:21:03AM -0500, Nicholas Krause wrote:
> On 12/12/19 4:11 AM, Segher Boessenkool wrote:
> >On Sun, Dec 08, 2019 at 03:03:56PM -0500, Nicholas Krause wrote:
> >>The first questions are:
> >>1. What current heuristics do we have as it seems non
Hi Nick,
On Sun, Dec 08, 2019 at 03:03:56PM -0500, Nicholas Krause wrote:
> The first questions are:
> 1. What current heuristics do we have as it seems none for figuring out
> what state is shared
> as it seems none? If I correct the first thing to do is discuss what
> bits/bitmasks we want
> f
On Fri, Dec 06, 2019 at 02:46:04PM -0500, Eric S. Raymond wrote:
> Experience matters at this. So does staying away from tools like git-svn that
> are known to be bad.
git-svn is an excellent tool, if you use it for something it is fit for.
And that is what Maxim did. Knowing what tool to use ho
On Thu, Dec 05, 2019 at 11:55:12AM +0300, Maxim Kuvyrkov wrote:
> > On Dec 3, 2019, at 11:10 PM, Richard Earnshaw (lists)
> > wrote:
> > And see above for the type of fetch spec you'd need to pull and see them
> > locally, with the structure I suggest, you can even write
> >
> > fetch = refs
On Wed, Dec 04, 2019 at 09:53:31AM +, Richard Earnshaw (lists) wrote:
> On 03/12/2019 22:43, Segher Boessenkool wrote:
> >>But you've still got the ongoing branch death issue to deal with, and
> >>that was my point. If you want to keep them, and you don't want
On Thu, Dec 05, 2019 at 10:37:33PM +, Jonathan Wakely wrote:
> On Thu, 5 Dec 2019 at 22:19, Segher Boessenkool wrote:
> > Or you could write
> >
> > auto __c = (__builtin_memcmp(&*__first1, &*__first2, __len) <=> 0);
> > if (__c)
> >
On Thu, Dec 05, 2019 at 08:56:35PM +, Jonathan Wakely wrote:
> On Thu, 5 Dec 2019 at 20:07, Segher Boessenkool
> wrote:
> > On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote:
> > > C++17 introduces a nice feature, with rationale similar to declaring
> >
On Thu, Dec 05, 2019 at 03:38:15PM -0500, Marek Polacek wrote:
> On Thu, Dec 05, 2019 at 02:06:50PM -0600, Segher Boessenkool wrote:
> > > When you're forced to uglify every variable with a leading __ you run
> > > out of characters pretty damn quickly.
> >
> &g
On Thu, Dec 05, 2019 at 11:54:04AM -0700, Martin Sebor wrote:
> >> if (present)
> >>ptr
> >> = gfc_build_conditional_assign_expr (block,
> >> present,
> >> ptr,
On Thu, Dec 05, 2019 at 05:04:12PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 05, 2019 at 04:46:45PM +0100, Thomas Schwinge wrote:
> > On 2019-12-05T16:15:15+0100, Jakub Jelinek wrote:
> > > [...] much more indented though, but you could
> > > use a temporary, like:
> > > tree nulla
On Thu, Dec 05, 2019 at 04:44:21PM +, Michael Matz wrote:
> (oh a flame bait :) )
I will blissfully ignore that warning.
> On Thu, 5 Dec 2019, Thomas Schwinge wrote:
> I object to cluttering code in excuse for using sensible function names or
> temporaries that otherwise can help clearing up
Hi!
On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote:
> C++17 introduces a nice feature, with rationale similar to declaring
> variables in a for-loop init-statement:
>
> if (auto var = foo(); bar(var))
Similar to GNU C statement expressions, which are *also* only a good
idea to u
On Wed, Dec 04, 2019 at 08:37:17PM +, Joseph Myers wrote:
> On Wed, 4 Dec 2019, Segher Boessenkool wrote:
> > And, as I said before, a release branch is a totally different animal
> > from releases (release tags). We do this correctly now, let's keep it
> > that
On Wed, Dec 04, 2019 at 06:25:21PM +, Joseph Myers wrote:
> In my current script (adjust-refs in the gcc-conversion repository;
> limited testing done based on a GCC repository conversion from last week,
> running a fresh conversion now with vendor tags kept for more testing),
> I'm using re
On Tue, Dec 03, 2019 at 08:10:37PM +, Richard Earnshaw (lists) wrote:
> On 03/12/2019 18:56, Segher Boessenkool wrote:
> > On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
> >>> But we could make an "old-svn" hierarchy or similar that ju
On Tue, Dec 03, 2019 at 09:16:43AM +, Richard Earnshaw (lists) wrote:
> On 03/12/2019 00:56, Segher Boessenkool wrote:
> >That sounds simpler than it is... After using this for a while you'll
> >get names that you want to delete, but that name *already* is in
> >/r
On Mon, Dec 02, 2019 at 08:37:14PM +, Joseph Myers wrote:
> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
> > Thanks for the list. As far as I can see all of those are no longer
> > useful, so they could be jut deleted from the SVN repo (if everyone
> > else agrees!)
On Mon, Dec 02, 2019 at 08:24:47PM +, Joseph Myers wrote:
> On Mon, 2 Dec 2019, Segher Boessenkool wrote:
>
> > Sure; I'm just saying rewriting old commit messages in such a style that
> > they keep standing out from new ones is a bit of a weird choice.
>
> I
On Mon, Dec 02, 2019 at 05:47:08PM +, Richard Earnshaw (lists) wrote:
> On 02/12/2019 17:25, Segher Boessenkool wrote:
> > On Mon, Dec 02, 2019 at 04:18:59PM +, Richard Earnshaw (lists) wrote:
> >> On 02/12/2019 15:35, Segher Boessenkool wrote:
> >>> On M
On Fri, Nov 29, 2019 at 10:31:22PM +, Joseph Myers wrote:
> On Fri, 29 Nov 2019, Segher Boessenkool wrote:
> > Please post the full names of all the tags you want to delete?
>
> Here is a list of 645 tags proposed for removal, in the various
> categories I gave. Vendor tags
On Mon, Dec 02, 2019 at 04:18:59PM +, Richard Earnshaw (lists) wrote:
> On 02/12/2019 15:35, Segher Boessenkool wrote:
> > On Mon, Dec 02, 2019 at 10:54:17AM +, Richard Earnshaw (lists) wrote:
> >> - author attributions are sometimes incorrect - reported
> >
&
Hi,
On Mon, Dec 02, 2019 at 10:54:17AM +, Richard Earnshaw (lists) wrote:
> - author attributions are sometimes incorrect - reported
This would disqualify that "conversion", for me at least. Keeping all
warts we had in SVN is better than adding new lies, lies about important
matters even.
On Fri, Nov 29, 2019 at 04:57:30PM +, Joseph Myers wrote:
> On Fri, 29 Nov 2019, Richard Earnshaw (lists) wrote:
>
> > I'm not convinced these should be just deleted. At least, not without the
> > specific vendor's agreement. But perhaps they should not be in the default
> > refs/tags namesp
On Fri, Nov 22, 2019 at 11:36:18PM +0100, Jakub Jelinek wrote:
> On Fri, Nov 22, 2019 at 04:01:43PM -0600, Segher Boessenkool wrote:
> > On Fri, Nov 22, 2019 at 09:02:05PM +, Andrew Dean wrote:
> > > > > Many systems do not have a system compiler newer than this *four
On Fri, Nov 22, 2019 at 09:02:05PM +, Andrew Dean wrote:
> > > Many systems do not have a system compiler newer than this *four years
> > > old* one. GCC 4.8 is the first GCC version that supports all of
> > > C++11, which is the only reason it would be even near acceptable to
> > > require so
On Wed, Nov 20, 2019 at 09:25:19AM -0500, Jason Merrill wrote:
> On Wed, Nov 20, 2019 at 6:27 AM Segher Boessenkool <
> seg...@kernel.crashing.org> wrote:
>
> > It would be good if whatever convention we do for commit messages and
> > their first line would be machine
On Wed, Nov 20, 2019 at 11:30:36AM +, Richard Earnshaw (lists) wrote:
> On 20/11/2019 11:27, Segher Boessenkool wrote:
> >On Wed, Nov 20, 2019 at 08:58:05AM +, Jonathan Wakely wrote:
> >>These won't work once we move to Git though.
> >
> >It would be go
On Wed, Nov 20, 2019 at 08:58:05AM +, Jonathan Wakely wrote:
> > Most of the time after I type "git log" I type "/\<123456\>". We need
> > to keep a way to easily map SVN revision ids to git commits, and
>
> As a aside, I use these aliases often with the current git-svn repo:
>
> $ git help
On Tue, Nov 19, 2019 at 02:36:21PM -0500, Eric S. Raymond wrote:
> Jason Merrill :
> > Well, I was thinking of also giving some clue of what the commit was
> > about. One possibly cut-off line accomplishes that, a simple revision
> > number not so much.
Sure, but it isn't easy at all to automatic
On Tue, Nov 19, 2019 at 09:56:50AM -0500, Jason Merrill wrote:
> Yep. I don't think we need to worry about getting optimal one-line
> summaries for ancient commits; something reasonably unique should be plenty.
In that case, how about just "SVN rNN"? And then we don't need the
footer from git
On Mon, Nov 18, 2019 at 07:21:22PM +, Richard Earnshaw (lists) wrote:
> On 18/11/2019 18:53, Segher Boessenkool wrote:
> > PR target/92140: clang vs gcc optimizing with adc/sbb
> > PR fortran/91926: assumed rank optional
> > PR tree-optimization/91532: [SVE] Redundan
On Mon, Nov 18, 2019 at 05:38:14PM +, Richard Earnshaw (lists) wrote:
> On 18/11/2019 17:11, Segher Boessenkool wrote:
> >I think that non-obviously-wrong-but-still-wrong info is not something
> >we should introduce. And, I think this will happen a *lot*.
> >
> &g
Hi Richard,
On Mon, Nov 18, 2019 at 04:48:03PM +, Richard Earnshaw (lists) wrote:
> On 18/11/2019 15:55, Segher Boessenkool wrote:
> >That immediately shows some of the shortcomings of this approach: the
> >subject line is much too long, but more importantly, it doesn't ma
Hi!
On Mon, Nov 18, 2019 at 03:32:06PM +, Richard Earnshaw (lists) wrote:
> I wrote this script for two reasons
>1) To learn some python (finally I had a good reason to go and do
> this :)
So I am last now? Heh.
>2) To try to improve some of our legacy commit messages, especially
Hi!
On Tue, Nov 05, 2019 at 09:50:37AM -0500, David Malcolm wrote:
> FWIW my convention has been to put "[PATCH]" in the email subject line
> for patches I want reviewed, and "[committed]" for patches that I've
> already self-approved (or are obvious) and thus don't need review.
And there is [RFC
On Tue, Nov 05, 2019 at 11:07:05AM +, Jonathan Wakely wrote:
> On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
> > I've been using git-style commit messages in GCC for the past five years.
>
> I think I only started four years ago :-)
I amr210190 Wed May 7 22:00:58 2014 +
Josep
On Mon, Nov 04, 2019 at 05:42:47PM +, Joseph Myers wrote:
> This is also why I don't care for [PATCH] tags at the
> start of subject lines - they take away space for saying what the patch is
> about, and on gcc-patches we can expect things are patches, [PATCH]
> doesn't add useful informatio
On Mon, Nov 04, 2019 at 01:43:17PM +0100, Martin Jambor wrote:
> On Mon, Nov 04 2019, Richard Earnshaw (lists) wrote:
> > Some tools, particularly gitk or git log --oneline, can use one-line
> > summaries from a commit's log message when listing commits. It would be
> > nice if we could start ad
On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote:
> I've already proposed a more specific format for libstdc++:
> https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
PR libstdc++/12345 takes up the first 19 chars of the short subject,
adding no useful information (unless the read
On Sat, Nov 02, 2019 at 10:14:15AM -0600, Jeff Law wrote:
> On 11/2/19 9:51 AM, Georg-Johann Lay wrote:
> > Segher Boessenkool schrieb:
> >>> Btw, does GCC support clobbering registers in branches (or
> >>> cbranch4 for that matter)? This requirement would come u
On Thu, Oct 31, 2019 at 11:46:27PM +0100, Georg-Johann Lay wrote:
> For AVR -- an other port affected by cc0 removal -- there is a
> LLVM/Clang port. It' not as mature as GCC's avr port, but what counts
> in the end is support / responsiveness from the community and an
> openness for the requir
On Mon, Oct 28, 2019 at 03:41:13PM -0600, Jeff Law wrote:
> On 10/28/19 2:27 PM, Segher Boessenkool wrote:
> > On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
> >> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> >>> Jason, Jonathan - is the situation on the
On Mon, Oct 28, 2019 at 01:40:03PM -0600, Jeff Law wrote:
> On 10/25/19 6:01 PM, Gabriel Dos Reis wrote:
> > Jason, Jonathan - is the situation on the terrain really that dire that
> > C++11 (or C++14) isn't at all available for platforms that GCC is
> > bootstrapped from?
> The argument that I'd
On Wed, Oct 02, 2019 at 10:39:23AM +0100, Richard Earnshaw (lists) wrote:
> There are some target hooks in combine that might help here.
> targetm.cannot_copy_insn_p and targetm.legitimate_combined_insn. The
> former is used more widely than just combine, so you might need to be
> careful that
On Tue, Oct 01, 2019 at 01:12:06PM +0100, Andrew Stubbs wrote:
> On 23/09/2019 15:39, Andrew Stubbs wrote:
> >On 23/09/2019 15:15, Segher Boessenkool wrote:
> >>On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
> >>> [(set (match_operand:D
On Wed, Sep 25, 2019 at 04:49:58PM +, Joseph Myers wrote:
> A version of the conversion using @gcc.gnu.org addresses is now available:
>
> git clone git+ssh://gcc.gnu.org/home/gccadmin/wwwdocs-test2.git
This looks great, thanks!
Can we test committing to this repo as well? Are hooks set up
On Wed, Sep 25, 2019 at 12:02:42PM +0100, Jonathan Wakely wrote:
> I mean that there's not much value in having my past commits listed as
> coming from various "different" authors:
>
> Jonathan Wakely
> Jonathan Wakely
> Jonathan Wakely
> Jonathan Wakely
> Jonathan Wakely
>
> All of those "i
On Mon, Sep 23, 2019 at 06:56:12PM +0100, Jozef Lawrynowicz wrote:
> > It could have just done that as
> >
> > (set (reg:PSI 28)
> > (zero_extend:PSI (reg:QI 12)))
> >
> > as far as I can see? Do you already have a machine pattern that matches
> > that?
>
> Yes that combination is what I w
On Mon, Sep 23, 2019 at 12:56:20PM +0100, Jozef Lawrynowicz wrote:
> (insn 2 4 3 2 (set (reg/v:HI 25 [ i ])
> (zero_extend:HI (reg:QI 12 R12 [ i ])))
> (nil))
> .
> (insn 7 6 8 2 (set (reg:PSI 28)
> (subreg:PSI (sign_extend:SI (reg/v:HI 25 [ i ])) 0))
> (nil))
>
> All
On Mon, Sep 23, 2019 at 03:39:08PM +0100, Andrew Stubbs wrote:
> On 23/09/2019 15:15, Segher Boessenkool wrote:
> >On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
> >> [(set (match_operand:DI 0 "register_operand" "=Sg,v")
> >>
On Mon, Sep 23, 2019 at 11:56:27AM +0100, Andrew Stubbs wrote:
> [(set (match_operand:DI 0 "register_operand" "=Sg,v")
> (ashift:DI
> (match_operand:DI 1 "gcn_alu_operand" " Sg,v")
> (match_operand:SI 2 "gcn_alu_operand" " Sg,v")))
>(clobber (match_scratch:BI 3
On Sat, Sep 21, 2019 at 11:39:38AM +0200, Andreas Schwab wrote:
> On Sep 21 2019, Segher Boessenkool wrote:
>
> > On Fri, Sep 20, 2019 at 09:49:36AM -0600, Jeff Law wrote:
> >> With the SVN repo going read-only it becomes our fallback plan in case
> >>
Hi!
On Wed, Sep 18, 2019 at 01:08:50PM +, Bernd Edlinger wrote:
> I'm currently trying to add -Wshadow=local to the gcc build rules.
> I started with -Wshadow, but gave up that idea immediately.
>
> As you could expect the current code base has plenty of shadowed
> local variables. Most are
On Tue, Sep 17, 2019 at 01:02:20PM +0100, Richard Earnshaw (lists) wrote:
> At the Cauldron this weekend the overwhelming view for the move to GIT
> soon was finally expressed.
[ cutting and pasting a bit ]
> There should be NO CHANGE to the other processes and policies that we
> have, eg patch
On Fri, Sep 20, 2019 at 09:49:36AM -0600, Jeff Law wrote:
> With the SVN repo going read-only it becomes our fallback plan in case
> of major unexpected problems.
>
> Joseph's recommendation for having the old objects/refs in the new repo
> makes a lot of sense. So if it works, it's got my support
Hi Tejas,
On Mon, Sep 02, 2019 at 08:55:28AM +0530, Tejas Joshi wrote:
> On Sat, 31 Aug 2019 at 02:05, Segher Boessenkool
> wrote:
> >
> > > > > > [ Please don't top-post ]
> >
> > (I delete everything under your signature, without looking, ass
> > > > [ Please don't top-post ]
(I delete everything under your signature, without looking, assuming you
just forgot to).
On Sat, Aug 31, 2019 at 12:48:42AM +0530, Tejas Joshi wrote:
> > For ISA 2.07 (Power 8) you don't have IEEE128 at all, not in hardware
> > that is. I don't know if we'll wa
Hi!
On Tue, Aug 27, 2019 at 09:37:59AM -0700, Michael Eager wrote:
> Combine is complex, but I don't think that target descriptions should
> conform to its behaviors;
But they have to, in some ways. If combine writes something that can be
written in multiple ways in some way X, then your machin
> > [ Please don't top-post ]
On Mon, Aug 26, 2019 at 12:43:44PM +0530, Tejas Joshi wrote:
> Sorry for not being clear. I am confused about some modes here. I
> meant, just as we expanded fadd (which narrows down from double to
> float) with add_truncdfsf3, how can I expand faddl (which narrows do
[ Please don't top-post ]
On Sun, Aug 25, 2019 at 07:32:01PM +0530, Tejas Joshi wrote:
> I want to extend this patch for FADDL and DADDL. What operand
> constraints should I use for TFmode alongside "f"?
It depends on the instruction you use, and what registers that then
works on. GPRs get "r",
Hi!
On Fri, Aug 23, 2019 at 07:16:59PM +0200, Martin Jambor wrote:
> Therefore, at least for now (GSoC deadline is kind of looming), I
> decided that the best way forward would be to not rely on internal
> functions but plug into expand_builtin() and I wrote the following,
> lightly tested patch -
> > Hi Tejas,
> >
> > [ Please do not top-post. ]
On Thu, Aug 22, 2019 at 01:27:06PM +0530, Tejas Joshi wrote:
> > What happens then? "It does not work" is very very vague. At least it
> > seems the compiler does build now?
>
> Oh, compiler builds but instruction is still "bl fadd". It should b
Hi Tejas,
[ Please do not top-post. ]
On Thu, Aug 22, 2019 at 09:09:37AM +0530, Tejas Joshi wrote:
> Yes, I tried basically every combination I could think of, just not
> with the "isa attr". Now, I have the following code and it is still
> seems not to be working. Am I missing any options to pas
On Wed, Aug 21, 2019 at 01:28:52PM -0500, Segher Boessenkool wrote:
> (define_insn "add_truncdfsf3"
> [(set (match_operand:SF 0 "gpc_reg_operand" "=,wa")
> (unspec:SF [(match_operand:DF 1 "gpc_reg_operand" "%,wa")
>
Hi Tejas,
On Wed, Aug 21, 2019 at 10:56:51PM +0530, Tejas Joshi wrote:
> I have the following code which uses unspec but I am really missing
> something here. Does unspec not work encapsulating plus? Or I have
> some more places to make changes to?
>
> (define_insn "add_truncdfsf3"
> [(set (mat
On Tue, Aug 20, 2019 at 03:43:43PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> >> [(set (match_operand:SI 0 "register_opera
On Tue, Aug 20, 2019 at 01:59:06PM +0100, Richard Sandiford wrote:
> Segher Boessenkool writes:
> >> [(set (match_operand:SI 0 "register_operand" "=d")
> >> (truncate:SI
> >> (lshiftrt:DI
> >
> > (this is optimis
On Tue, Aug 20, 2019 at 08:41:29AM +0100, Richard Sandiford wrote:
> Tejas: given the controversy, I agree unspecs sound like a good approach
> for now. We can always go back and add the rtx codes later once there's
> agreement on what they should look like.
Yup.
> Segher Bo
t;
> > (and many variations) Unfortunately, any moderately complicated input
> > still results in a (mem (reg) ) insn repeatedly entering the
> > lra_in_progress case and returning false, and eventually terminating with
> >
> > "internal compiler error:
Hi Richard,
On Sat, Aug 17, 2019 at 09:21:00AM +0100, Richard Sandiford wrote:
> Tejas Joshi writes:
> >> It's just a different name, nothing more, nothing less. Because it is
> >> a different name it can not be accidentally generated from actual
> >> truncations.
> >
> > I have introduced float
On Thu, Aug 15, 2019 at 02:30:19PM -0400, Vladimir Makarov wrote:
> >Couldn't we spill the frame pointer? Basically we should be able to
> >compute the first address into a reg, spill that, do the second (both
> >could require the frame pointer), spill the frame pointer, reload the
> >first comp
On Thu, Aug 15, 2019 at 03:29:03PM +0530, Tejas Joshi wrote:
> Also, in what manner should float_contract/narrow be different from
> float_truncate as both are trying to do similar things? (truncation
> from DF to SF)
It's just a different name, nothing more, nothing less. Because it is
a differe
On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote:
> Tejas Joshi writes:
> > Hello.
> > I just wanted to make sure that I am looking at the correct code here.
> > Except for rtl.def where I should be introducing something like
> > float_contract (or float_narrow?) and also simplify
On Wed, Aug 14, 2019 at 08:23:27PM +, Joseph Myers wrote:
> On Wed, 14 Aug 2019, Segher Boessenkool wrote:
>
> > Does something like
> > float d; double a, b, x;
> > ...
> > d = fadd (a + x, b - x);
> > work as wanted, with such a representation? It
On Wed, Aug 14, 2019 at 04:10:56PM +, Joseph Myers wrote:
> On Wed, 14 Aug 2019, Segher Boessenkool wrote:
>
> > I think you can do one RTL code that replaces float_truncate in
> >
> > > > > > (define_insn "add_truncdfsf3"
> > > >
On Wed, Aug 14, 2019 at 11:51:28AM +0530, Tejas Joshi wrote:
> > The RTL needs to be something that
> > does *not* match the combination of separate operations (just as fma has
> > its own RTL, and a separate pass is responsible for converting separate
>
> So do I need to introduce fadd's own RTL
On Mon, Aug 12, 2019 at 09:20:18PM +, Joseph Myers wrote:
> On Mon, 12 Aug 2019, Segher Boessenkool wrote:
>
> > (define_insn "add_truncdfsf3"
> > [(set (match_operand:SF 0 "gpc_reg_operand" "=f,wa")
> > (float_truncate:SF
> >
On Mon, Aug 12, 2019 at 11:01:11PM +0530, Tejas Joshi wrote:
> I have the following code in my rs6000.md (I haven't used new TARGET_* yet) :
>
> (define_expand "add_truncdfsf3"
> [(set (match_operand:SF 0 "gpc_reg_operand")
>(float_truncate:SF
>(plus:DF (match_operand:DF 1 "gpc_r
Hi John,
On Mon, Aug 12, 2019 at 08:47:43AM +0200, John Darrington wrote:
> On Sat, Aug 10, 2019 at 11:12:18AM -0500, Segher Boessenkool wrote:
> On Sat, Aug 10, 2019 at 08:05:53AM +0200, John Darrington wrote:
> > Choosing alt 5 in insn 14: (0) m (1) m {*movsi}
&g
Hi Tejas,
On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote:
> +(define_expand "add_truncdfsf3"
> + [(set (float_extend:DF (match_operand:SF 0 "gpc_reg_operand"))
> + (plus:DF (match_operand:DF 1 "gpc_reg_operand")
> + (match_operand:DF 2 "gpc_reg_operand")))]
> + "TAR
Hi Tejas,
On Sun, Aug 11, 2019 at 10:34:26AM +0530, Tejas Joshi wrote:
> > As far as I understand that flag should set the behaviour of the fadd
> > function, not the __builtin_fadd one. So I don't know.
>
> According to ISO/IEC TS 18661, I am supposed to implement the fadd
> variants for foldin
Hi!
On Sat, Aug 10, 2019 at 12:12:46PM +0200, Jakub Jelinek wrote:
> On Sat, Aug 10, 2019 at 08:53:45AM +0200, Hans-Peter Nilsson wrote:
> > Has there been a change of policy so it's a valid option to use
> > gcc/ChangeLog for testsuite changes? I was about to move a
> > semi-randomly spotted mis
Hi!
On Sat, Aug 10, 2019 at 04:00:53PM +0530, Tejas Joshi wrote:
> I have been trying to write a basic pattern taking all the suggestions
> you both have mentioned. The same patch is attached here, but I cannot
> see call to :
>
> float
> foo (double x, double y)
> {
> return __builtin_fadd (
On Sat, Aug 10, 2019 at 08:10:27AM +0200, John Darrington wrote:
> On Fri, Aug 09, 2019 at 09:16:44AM -0500, Segher Boessenkool wrote:
>
> Is your code in some branch in our git?
>
> No. But it could be pushed there if people think it would be
> appropriate to do so, an
Hi!
On Sat, Aug 10, 2019 at 08:05:53AM +0200, John Darrington wrote:
>Choosing alt 5 in insn 14: (0) m (1) m {*movsi}
>14: [r40:PSI+0x20]=[r41:PSI]
> Inserting insn reload before:
>48: r40:PSI=r34:PSI
>49: r41:PSI=[y:PSI+0x2f]
insn 14 is a mem-to-mem move (another featur
Hi!
On Fri, Aug 09, 2019 at 10:14:39AM +0200, John Darrington wrote:
> On Thu, Aug 08, 2019 at 01:57:41PM -0600, Jeff Law wrote:
>
> Yea, it's certainly designed with the more mainstream architectures in
> mind. THe double-indirect case that's being talked about here is well
> out
Hi!
On Fri, Aug 09, 2019 at 12:14:54AM +0530, Tejas Joshi wrote:
> > In GCC (in rs6000.md) we have the "*add3_fpr" and similar insns,
> > which could be extended to allow DF inputs with an SF output; it doesn't
> > yet allow it.
>
> This might be very lousy but I am confused with the optabs and i
201 - 300 of 685 matches
Mail list logo
