On Sun, Jan 12, 2020 at 01:31:13PM +, Iain Sandoe wrote:
> Segher Boessenkool wrote:
> > Why would people want to name their local branches "me/thing" instead
> > of just "thing", btw?
>
> it’s a way of making things distinct and allows the push ru
Hi!
On Thu, Jan 16, 2020 at 05:36:52PM +0800, Kewen.Lin wrote:
> As we discussed in the thread
> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00196.html
> Original: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00104.html,
> I'm working to teach IVOPTs to consider D-form group access during unrol
Hi!
On Thu, Jan 16, 2020 at 05:39:40PM +0800, Kewen.Lin wrote:
> --- a/gcc/cfgloop.h
> +++ b/gcc/cfgloop.h
> @@ -232,6 +232,9 @@ public:
> Other values means unroll with the given unrolling factor. */
>unsigned short unroll;
>
> + /* Like unroll field above, but it's estimated in mid
Hi!
On Mon, Jan 20, 2020 at 10:42:12AM +, Richard Sandiford wrote:
> "Kewen.Lin" writes:
> > gcc/ChangeLog
> >
> > 2020-01-16 Kewen Lin
> >
> > * config/rs6000/rs6000.c (TARGET_STRIDE_DFORM_VALID_P): New macro.
> > (rs6000_stride_dform_valid_p): New function.
> > * doc/tm.texi:
Hi!
On Thu, Jan 16, 2020 at 05:42:41PM +0800, Kewen.Lin wrote:
> +/* At time the dform optimization pass was merged with trunk, 12
> + lxv instructions were emitted in place of the same number of lxvx
> + instructions. No need to require exactly this number, as it may
> + change when other
Hi!
On Mon, Jan 20, 2020 at 01:47:56PM +, Wilco Dijkstra wrote:
> Would it not make more sense to use the TARGET_ADDRESS_COST hook
> to return different costs for immediate offset and register offset addressing,
> and ensure IVOpts correctly takes this into account?
>
> On AArch64 we've defin
Hi!
On Mon, Jan 20, 2020 at 11:52:55PM +0100, Jakub Jelinek wrote:
> PR target/93073
> * config/rs6000/rs6000.c (rs6000_emit_cmove): Punt for compare_mode
> other than SFmode or DFmode.
"If using fsel, punt for..." etc.
> + /* Don't allow compare_mode other than SFmode or DFmo
On Tue, Jan 21, 2020 at 12:23:02AM +0100, Jakub Jelinek wrote:
> On Mon, Jan 20, 2020 at 05:10:55PM -0600, Segher Boessenkool wrote:
> > On Mon, Jan 20, 2020 at 11:52:55PM +0100, Jakub Jelinek wrote:
> > > PR target/93073
> > > * config/rs6000/rs6000.c (r
Hi!
On Mon, Jan 20, 2020 at 08:31:43PM -0500, Nicholas Krause wrote:
> On 1/20/20 6:51 PM, Segher Boessenkool wrote:
> >We can (and should) use other instructions than just fsel here as well
> >(say, xscmpgedp followed by xxsel). This can also work for QP float,
> >which als
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
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
Hi!
On Mon, Jan 06, 2020 at 09:24:10AM +0100, Jakub Jelinek wrote:
> 1) always use gen_add3_insn, but if it returns NULL use the extra
> emit_move_insn (end_addr, GEN_INT (-rounded_size));
> and retry with end_addr instead of rs
> 2) if the first gen_add3_insn returned NULL or if it created more t
Hi!
On Thu, Jan 16, 2020 at 12:50:14PM +, Wilco Dijkstra wrote:
> The separate shrinkwrapping pass may insert stores in the middle
> of atomics loops which can cause issues on some implementations.
> Avoid this by delaying splitting of atomic patterns until after
> prolog/epilog generation.
N
On Mon, Jan 13, 2020 at 01:12:15PM -0500, Eric S. Raymond wrote:
> Jonathan Wakely :
> > Email the patches to gcc-patches@gcc.gnu.org, that's how things get
> > merged.
> >
> > We're not looking to change any workflows now.
>
> Roger that.
>
> Once the dust from the conversion has settled, thoug
Hi!
On Tue, Jan 21, 2020 at 02:10:21PM +, Wilco Dijkstra wrote:
> While code hoisting generally improves codesize, it can affect performance
> negatively. Benchmarking shows it doesn't help SPEC and negatively affects
> embedded benchmarks. Since the impact is relatively small with -O2 and mai
Hi!
On Wed, Jan 22, 2020 at 07:11:27AM +0100, Hans-Peter Nilsson wrote:
> I intend to put back as many as I find use for, of those
> anonymous patterns in a controlled manner, with self-contained
> test-cases proving their usability, rather than symmetry with
> other instructions and similar addre
Hi!
On Mon, Jan 27, 2020 at 04:28:29PM +, Wilco Dijkstra wrote:
> > On Thu, Jan 16, 2020 at 12:50:14PM +, Wilco Dijkstra wrote:
> >> The separate shrinkwrapping pass may insert stores in the middle
> >> of atomics loops which can cause issues on some implementations.
> >> Avoid this by del
On Tue, Jan 28, 2020 at 10:42:16AM +0100, Richard Biener wrote:
> On Mon, Jan 27, 2020 at 10:47 PM Segher Boessenkool
> wrote:
> > On Tue, Jan 21, 2020 at 02:10:21PM +, Wilco Dijkstra wrote:
> > > While code hoisting generally improves codesize, it can affect perform
On Tue, Jan 28, 2020 at 10:43:24AM +, Richard Sandiford wrote:
> Tested on aarch64-linux-gnu, x86_64-linux-gnu and powerpc64le-linux-gnu.
> OK to install?
Yes, thank you.
Segher
> 2020-01-28 Richard Sandiford
>
> gcc/testsuite/
> PR testsuite/93393
> * gcc.dg/torture/pr9313
This is my current work-in-progress version. There still are rough
edges, and not much is done for the output modifiers yet, but it should
be in much better shape wrt the user manual now. The internals manual
also is a bit better I think.
md.texi is not automatically kept in synch with constrain
Hi!
On Fri, Jan 31, 2020 at 10:12:08AM +, Tamar Christina wrote:
> This fixes a fall-out from a patch I had submitted two years ago which started
> allowing simplify-rtx to fold logical right shifts by offsets a followed by b
> into >> (a + b).
>
> However this can generate inefficient code w
Hi!
On Thu, Jan 09, 2020 at 06:52:05PM -0500, Michael Meissner wrote:
> 2020-01-09 Michael Meissner
>
> * config/rs6000/rs6000.c (rs6000_adjust_vec_address): Add some
> gcc_asserts.
> + /* All insns should use the 'Q' constraint (address is a single
> register)
> + if t
Hi Bill,
Thanks a lot for looking at this! :-)
On Fri, Jan 31, 2020 at 08:49:21AM -0600, Bill Schmidt wrote:
> >+(define_register_constraint "wa"
> >"rs6000_constraints[RS6000_CONSTRAINT_wa]"
> >+ "A VSX register (VSR), @code{vs0}@dots{}@code{vs63}. Either a @code{d}
> >+ or a @code{v} regi
Hi!
On Thu, Jan 09, 2020 at 07:04:10PM -0500, Michael Meissner wrote:
> 2020-01-09 Michael Meissner
>
> * config/rs6000/rs6000.c (get_vector_offset): New helper function
> to calculate the offset in memory from the start of a vector of a
> particular element. Add code to kee
On Fri, Jan 31, 2020 at 10:56:10AM -0600, Bill Schmidt wrote:
> On 1/31/20 9:42 AM, Segher Boessenkool wrote:
> >On Fri, Jan 31, 2020 at 08:49:21AM -0600, Bill Schmidt wrote:
> >>>+(define_register_constraint "wa"
> >>>"rs6000_constraints[RS6000_CONS
Hi!
Thanks for working on this.
On Fri, Jan 31, 2020 at 04:59:02PM +, Bernd Edlinger wrote:
> I will try to improve the patch a bit, and hope you are gonna like
> it. I agree that this feature is fine, and should be enabled by
> default, and just if it is positively clear that it won't work,
Hi!
On Thu, Jan 09, 2020 at 07:27:58PM -0500, Michael Meissner wrote:
> * config/rs6000/rs6000.c (reg_to_non_prefixed): Add forward
> reference.
FWIW, it is better to just reorder the code, in most cases.
> (hard_reg_and_mode_to_addr_mask): Delete, no longer used.
Just "Delete
Hi!
On Thu, Jan 09, 2020 at 07:34:31PM -0500, Michael Meissner wrote:
> +static rtx
> +adjust_vec_address_pcrel (rtx addr, rtx element_offset, rtx base_tmp)
> +{
> + rtx new_addr = NULL;
You don't need this variable, you can just return the value directly in
every case, and then you don't need a
Hi!
On Thu, Jan 09, 2020 at 07:40:08PM -0500, Michael Meissner wrote:
> * config/rs6000/linux64.h (PREFIXED_ADDR_SUPPORTED_BY_OS): Set to
> 1 to enable prefixed addressing if -mcpu=future.
> (PCREL_SUPPORTED_BY_OS): Set to 1 to enable PC-relative addressing
> if -mcpu=futur
On Fri, Jan 31, 2020 at 11:38:04PM +, Bernd Edlinger wrote:
> On 1/31/20 11:54 PM, Segher Boessenkool wrote:
> > about most, which caused me to open PR93168, is TERM=screen (which is
> > what tmux uses), so at least exclude that one? And doing all this
>
> Definitely,
Hi!
On Sat, Feb 01, 2020 at 05:02:18AM +, Bernd Edlinger wrote:
> >> Definitely, if the situation with tmux is like xfce4-terminal (reportedly
> >> the 0.8 version switched to a fixed VTE, which makes the URLs invisible,
> >> but the URL feature request is pending sine 2017, with no activity
On Sat, Feb 01, 2020 at 08:41:15AM -0500, David Malcolm wrote:
> Does our existing colorization code not work with TMUX, or is it just the
> new URLs that are broken? Segher?
I don't know, I have colourisation turned off in GCC pretty much always
on systems I use with tmux. Some other programs t
On Sat, Feb 01, 2020 at 05:21:30PM +, Bernd Edlinger wrote:
> On 2/1/20 6:12 PM, Jakub Jelinek wrote:
> > On Sat, Feb 01, 2020 at 03:43:20PM +, Bernd Edlinger wrote:
> >> I seem to remember him saying that he always has to configure with
> >> --with-diagnostics-color=never, and the URLs are
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
On Sun, Feb 02, 2020 at 08:00:44AM +, Bernd Edlinger wrote:
> >> Okay, thanks. That is a strong indication that there is no need
> >> to interfere with screen, which proves that any auto-disabling should
> >> have a very specific terminal detection logic.
> >
> > Jakub says that he tested wit
(Old thread, first time I see it though):
On Mon, Jan 20, 2020 at 11:45:28AM +, Richard Earnshaw (lists) wrote:
> The more we make the process lightweight for contributors, the more work
> we make for maintainers. If the contribution is sent correctly, then
> ideally, the patch can be appli
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
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
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
This un-documents constraints that cannot (or should not) be used in
inline assembler. It also improves markup, and presentation in general.
More work is needed, but gradual improvement is easier to do.
Committing to trunk.
Segher
2020-02-03 Segher Boessenkool
* config/rs6000
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
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
On Mon, Feb 03, 2020 at 08:16:52PM +, Bernd Edlinger wrote:
> So gnome terminal is a problem, since it depend heavily on the software
> version, VTE library, and gnome-terminal.
> Sometimes URLs are functional, sometimes competely buggy.
>
> But, wait a moment, here is the deal:
>
> I can det
On Mon, Feb 03, 2020 at 04:52:42PM -0500, Michael Meissner wrote:
> > I understand why this is needed for pcrel (or useful at least), but why
> > for prefixed addressing in general as well? What OS support is needed
> > for that?
> >
> > Put another way, is this just carefulness, or do you run in
On Mon, Feb 03, 2020 at 05:02:25PM -0500, Michael Meissner wrote:
> On Fri, Jan 31, 2020 at 11:30:22AM -0600, Segher Boessenkool wrote:
> > But why is that the correct thing to do? Garbage in, garbage out is
> > perfectly fine? Or do we have (e.g.) builtins that specify this mas
On Mon, Feb 03, 2020 at 06:19:07PM -0500, Michael Meissner wrote:
> On Fri, Jan 31, 2020 at 05:43:20PM -0600, Segher Boessenkool wrote:
> > On Thu, Jan 09, 2020 at 07:27:58PM -0500, Michael Meissner wrote:
> > > * config/rs6000/rs6000.c (reg_to_non_prefixed): Add forward
Hi!
On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt wrote:
> The current built-in support in the rs6000 back end requires at least
> a master's degree in spelunking to comprehend. It's full of cruft,
> redundancy, and unused bits of code, and long overdue for a
> replacement. This is the
Hi!
On Mon, Feb 03, 2020 at 08:26:02PM -0600, Bill Schmidt wrote:
> Includes header documentation and initial set of include directives.
Please use full sentences in commit messages.
> +/* This program generates built-in function initialization and
> + recognition code for Power targets, based
Committed.
Segher
---
htdocs/git.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/git.html b/htdocs/git.html
index 66d68eb..7fd22a9 100644
--- a/htdocs/git.html
+++ b/htdocs/git.html
@@ -44,7 +44,7 @@ through, you can replace git:// with
https://.
If there is a
On Tue, Feb 04, 2020 at 03:10:32PM -0600, Bill Schmidt wrote:
> >I really don't think using the new acronym "bif" helps; built-in
> >functions already are often called "builtins" (or "intrinsics", which is
> >problematic itself).
>
> Until we manage to replace the old methods, we already have
> r
On Tue, Feb 04, 2020 at 04:44:04PM -0600, Bill Schmidt wrote:
> >"ldv" certainly is shorter and nicer in principle, but it is a bit
> >cryptic. As I said, it's probably not too hard to get used to it; and
> >maybe a better name will present itself?
> Maybe ldvec and stvec would serve without intro
Hi all,
On Wed, Feb 05, 2020 at 07:26:03AM +0100, Jakub Jelinek wrote:
> On Tue, Feb 04, 2020 at 06:04:09PM -0700, Jeff Law wrote:
> > --- a/gcc/cse.c
> > +++ b/gcc/cse.c
> > @@ -5572,6 +5572,16 @@ cse_insn (rtx_insn *insn)
> > sets[i].rtl = 0;
> > }
> >
> > + /* Similarly for no-
Hi!
On Wed, Feb 05, 2020 at 08:57:16AM +0100, Richard Biener wrote:
> On Tue, Feb 4, 2020 at 6:40 PM Segher Boessenkool
> wrote:
> > On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt wrote:
> > > My intent is to make adding new built-in functions as simple as adding
&
On Wed, Feb 05, 2020 at 09:53:27PM +0800, Jiufu Guo wrote:
> As PR93047 said, __builtin_apply/__builtin_return does not work well with
> -frename-registers. This is caused by return register(e.g. r3) is used to
> rename another register, before return register is stored to stack.
>
> This patch f
On Wed, Feb 05, 2020 at 04:29:38PM -0500, Michael Meissner wrote:
> 2020-02-05 Michael Meissner
>
> PR target/93568
> * config/rs6000/rs6000.c (get_vector_offset): Fix
>
> --- /tmp/a8cqkr_rs6000.c 2020-02-05 14:55:36.255021903 -0600
> +++ gcc/config/rs6000/rs6000.c2020
On Wed, Feb 05, 2020 at 11:48:23AM -0700, Jeff Law wrote:
> Yea, it's closely related. In your case you need to effectively ignore
> the nop insn to get the optimization you want. In mine that nop insn
> causes an ICE.
>
> I think we could take your cse bits + adding a !CALL_P separately from
>
Hi!
On Thu, Feb 06, 2020 at 11:26:23AM -0300, Matheus Castanho wrote:
> I recently faced problems while building GCC caused by a system header
> being broken by the machine_name fix from fixincludes [1]. And
> apparently I am not the first one [2][3].
>
> After digging into the fixincludes code,
Hi!
On Thu, Feb 06, 2020 at 10:49:36AM +0800, Jiufu Guo wrote:
> > emit_call_insn (gen_call (operands[0], const0_rtx, const0_rtx));
> >
> > for (i = 0; i < XVECLEN (operands[2], 0); i++)
> > {
> > rtx set = XVECEXP (operands[2], 0, i);
> > emit_move_insn (SET_DEST (set), SET_SR
Hi!
On Thu, Feb 06, 2020 at 08:29:41AM -0500, Michael Meissner wrote:
> --- /tmp/eAu61F_rs6000.c 2020-02-05 18:08:48.698992017 -0500
> +++ gcc/config/rs6000/rs6000.c2020-02-05 17:23:55.733650185 -0500
> @@ -24943,9 +24943,13 @@ reg_to_non_prefixed (rtx reg, machine_mo
> }
>
>
.
Segher
2020-02-06 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_emit_set_long_const): Handle the case
where the low and the high 32 bits are equal to each other specially,
with an rldimi instruction.
gcc/testsuite/
* gcc.target/powerpc/pr93012.c: New
Hi!
Sorry for dropping this once again.
On Thu, Jan 30, 2020 at 05:14:08PM +0100, Jakub Jelinek wrote:
> Here is what I meant as the alternative, i.e. don't check any predicates,
> just gen_add3_insn, if that fails, force rs into register and retry.
I don't like gen_add3_insn here *at all*, as I
Hi Will,
On Thu, Feb 06, 2020 at 11:41:47AM -0600, will schmidt wrote:
> The existing testcase pr92923-1.c uses vector long long, and thus
> requires vsx.
> OK for master?
Sure! Thanks for the patch.
> * testsuite/gcc.target/powerpc/pr92923-1.c: Add -mvsx.
The changelog is testsuit
On Thu, Feb 06, 2020 at 01:40:03PM -0500, Michael Meissner wrote:
> This patch addresses the concern the Segher raised in the original submission
> of the patch to fix PR target/93569. In addition to checking for D*-form
> addresses in the traditional Altivec registers, this patch also checks for
Hi again,
On Thu, Feb 06, 2020 at 08:51:06PM +0100, Jakub Jelinek wrote:
> On Thu, Feb 06, 2020 at 01:15:25PM -0600, Segher Boessenkool wrote:
> > On Thu, Jan 30, 2020 at 05:14:08PM +0100, Jakub Jelinek wrote:
> > > Here is what I meant as the alternative, i.e. don'
On Thu, Feb 06, 2020 at 12:13:35PM +0100, Uros Bizjak wrote:
> The names of split_before_sched2 ("split4") and split_before_regstack
> ("split3") do not reflect their insertion point in the sequence of passes,
> where split_before_regstack follows split_before_sched2. Reorder the code
> and rename
On Tue, Feb 04, 2020 at 02:55:14PM +0100, Martin Liska wrote:
>
> gcc/ChangeLog:
>
> 2020-02-04 Martin Liska
>
> PR c/92472.
That trailing dot should not be there (in some other patches as well).
Segher
Hi!
On Thu, Feb 06, 2020 at 05:16:14PM -0500, Vladimir Makarov wrote:
> --- a/gcc/lra-assigns.c
> +++ b/gcc/lra-assigns.c
> @@ -964,6 +964,8 @@ spill_for (int regno, bitmap spilled_pseudo_bitmap, bool
> first_p)
>bitmap_clear (&spill_pseudos_bitmap);
>for (j = hard_regno_nregs (ha
On Tue, Feb 04, 2020 at 12:06:54PM +, Richard Sandiford wrote:
> > Also, you don't need to emit "#" in output template. This is just for
> > extra safety, we can live without. Please see e.g. "*tzcnt_1".
>
> IMO it's better to keep it here, where we're relying on the split
> happening for corr
On Fri, Feb 07, 2020 at 06:01:44PM +, Richard Sandiford wrote:
> Wilco Dijkstra writes:
> > Although GCC should understand the limited range of clz/ctz/cls results,
> > Combine sometimes behaves oddly and duplicates ctz to remove an unnecessary
> > sign extension. Avoid this by adding an expl
On Fri, Feb 07, 2020 at 05:47:32PM +0100, Ulrich Weigand wrote:
> > but what happens to -fsignalling-nans -ffast-math then? Better leave those
> > in I'd say.
>
> Ah, it seems I was confused about the intended semantics here.
>
> I thought that a *more specific* option like -fsignalling-nans was
Hi!
On Fri, Feb 07, 2020 at 03:10:05PM +0800, Jiufu Guo wrote:
> Segher Boessenkool writes:
> > On Thu, Feb 06, 2020 at 10:49:36AM +0800, Jiufu Guo wrote:
> >> > ... and nothing in the rtl stream says that those return registers are
> >> > actually set b
On Fri, Feb 07, 2020 at 09:00:40AM -0700, Jeff Law wrote:
> On Thu, 2020-02-06 at 07:56 -0600, Segher Boessenkool wrote:
> > On Wed, Feb 05, 2020 at 11:48:23AM -0700, Jeff Law wrote:
> > > Yea, it's closely related. In your case you need to effectively ignore
> &
Hi!
On Fri, Feb 07, 2020 at 06:22:56PM -0600, Peter Bergner wrote:
> On 1/9/20 6:29 PM, Peter Bergner wrote:
> > On 1/9/20 4:51 PM, Segher Boessenkool wrote:
> >> Splitting out separate functions in the testcase shouldn't be so much
> >> work? Or am I too opti
Hi again,
On Sat, Feb 08, 2020 at 11:54:48AM +0100, Uros Bizjak wrote:
> On Fri, Feb 7, 2020 at 5:41 PM Segher Boessenkool
> wrote:
> > On Thu, Feb 06, 2020 at 12:13:35PM +0100, Uros Bizjak wrote:
> > > The names of split_before_sched2 ("split4") and split_before_r
On Sat, Feb 08, 2020 at 10:17:42AM -0600, Segher Boessenkool wrote:
> And we do not know which of the register will be used for the return, in
> untyped_call (only untyped-return knows). But we can add clobbers of all
> registers that *might* be used for the return, we do know that
On Mon, Feb 10, 2020 at 03:07:49PM +0100, Jakub Jelinek wrote:
> + || strncmp (name, ".lbss.", sizeof (".lbss.") - 1) == 0
You can just use strlen (".lbss.") which is nicer to read and compiles
to the same thing?
Segher
On Mon, Feb 10, 2020 at 10:05:48AM -0800, Andrew Benson wrote:
> I don't think I have the ability to mark the PR as resolved. Can someone do
> that?
You have an @gcc.gnu.org account; if you use that for your BZ account,
you will magically get everything you need here.
Segher
Hi!
On Mon, Feb 10, 2020 at 02:17:04PM +0800, Kewen.Lin wrote:
> on 2020/1/20 下午8:33, Segher Boessenkool wrote:
> > On Thu, Jan 16, 2020 at 05:36:52PM +0800, Kewen.Lin wrote:
> >> As we discussed in the thread
> >> https://gcc.gnu.org/ml/gcc-patches/2020-01/msg0019
Hi!
On Mon, Feb 10, 2020 at 02:20:17PM +0800, Kewen.Lin wrote:
> * tree-ssa-loop-manip.c (decide_uf_const_iter): New function.
> (decide_uf_runtime_iter): Likewise.
> (decide_uf_stupid): Likewise.
These names still use "uf". (Those are the last I see).
> * tree-ssa-loop-
On Mon, Feb 10, 2020 at 02:24:15PM +0800, Kewen.Lin wrote:
> 2020-02-10 Kelvin Nilsen
> Kewen Lin
>
> * gcc.target/powerpc/p9-dform-0.c: New test.
> * gcc.target/powerpc/p9-dform-1.c: New test.
> * gcc.target/powerpc/p9-dform-2.c: New test.
> * gcc.target/p
It is easier to read and understand strlen ("string") than it is to
read and understrand sizeof ("string") - 1 .
Tested on powerpc64-linux {-m32,-m64}. Committing to trunk.
Segher
2020-02-10 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_debug_pr
On Mon, Feb 10, 2020 at 07:07:46PM +0100, Jakub Jelinek wrote:
> We use sizeof ("...") - 1 or sizeof "..." - 1 in a lot of places though.
[...]
> config/rs6000/rs6000.c:spaces += sizeof (" Reload=sl") - 1;
> config/rs6000/rs6000.c:spaces += sizeof (" Upper=y") - 1;
> config/rs6000/rs600
Hi!
On Mon, Feb 10, 2020 at 01:45:42PM -0500, Michael Meissner wrote:
> This patch renames the PowerPC internal switch -mprefixed-addr to be
> -mprefixed.
> If you use -mpcrel, you must be using the 64-bit ELF v2 ABI, and the code
> model
> must be medium.
Currently, anyway.
> If you use -mpcr
Hi!
On Mon, Feb 10, 2020 at 03:39:44PM -0600, will schmidt wrote:
> This fixes up a few tests that explicitly disable vsx,
> but still require altivec be enabled by adding the -maltivec
> option. (Noted on AIX, also seen on Linux/Power6).
> diff --git a/gcc/testsuite/gcc.target/powerpc/pr7
Hi!
On Mon, Feb 10, 2020 at 03:39:49PM -0600, will schmidt wrote:
> This adds a target_supports entry to check that the
> _ieee128 keyword is understood by the target.
(Two underscores, "__ieee128".)
> Also adds that require-effective-target check to the
> existing pr92796 testcase.
> +# See if
Hi!
On Tue, Feb 11, 2020 at 02:50:03PM +0800, Kewen.Lin wrote:
> v3 changes:
> - Updated _uf to _unroll for some function names.
Thanks.
> By the way, should I guard the current i386/s390 loop_unroll_adjust
> ealy return with (current_pass->type != RTL_PASS)? I'm inclined not
> to, since this
On Mon, Feb 10, 2020 at 10:22:37PM -0600, Bill Schmidt wrote:
> On 2/10/20 9:24 PM, Segher Boessenkool wrote:
> >>If you use -mpcrel, the compiler will generate PC-relative
> >>loads and stores to access items, rather than the current TOC based loads
> >>and
> &g
On Tue, Feb 11, 2020 at 08:34:15AM +0100, Richard Biener wrote:
> On Mon, 10 Feb 2020, Segher Boessenkool wrote:
> > Yes, we should decide how often we want to unroll things somewhere before
> > ivopts already, and just use that info here.
> >
> > Or are there advant
On Tue, Feb 11, 2020 at 02:58:47PM +0100, Richard Biener wrote:
> On Tue, 11 Feb 2020, Roman Zhuykov wrote:
> > 11.02.2020 11:01, Richard Biener wrote:
> > Sound good, but IMHO modulo scheduler is not the best choice to be the
> > first step implementing such a concept.
>
> True ;) But since the
Hi!
On Tue, Feb 11, 2020 at 03:46:05PM +0300, Roman Zhuykov wrote:
> Hmm, even when trying to move it just few passes earlier many years ago,
> got another opinion:
> https://gcc.gnu.org/ml/gcc-patches/2011-10/msg01526.html
> Although without such a move we still have annoying issues which RTL
> f
Hi!
On Tue, Feb 11, 2020 at 12:10:50PM -0600, will schmidt wrote:
> +# See if the __ieee128 keyword is understood.
> +proc check_effective_target_ppc_ieee128_ok { } {
> +return [check_cached_effective_target ppc_ieee128_ok {
> + # disable on AIX.
> + if { [istarget *-*-aix*] } {
> +
Hi!
On Tue, Feb 11, 2020 at 07:43:31PM +0100, Ulrich Weigand wrote:
> 1. If a component flag of -ffast-math (or -funsafe-math-optimizations)
>is explicitly set (or reset) on the command line, this should override
>any implicit change due to -f(no-)fast-math, no matter in which order
>t
On Wed, Feb 12, 2020 at 09:12:58AM +0100, Richard Biener wrote:
> On Tue, 11 Feb 2020, Segher Boessenkool wrote:
> > Basic block partitioning has wildly disproportionate fallout in all
> > later passes, both in terms of what those *do* (or don't, if partitioning
> > is
On Wed, Feb 12, 2020 at 09:07:27AM +0100, Richard Biener wrote:
> On Tue, 11 Feb 2020, Segher Boessenkool wrote:
>
> > On Tue, Feb 11, 2020 at 02:58:47PM +0100, Richard Biener wrote:
> > > On Tue, 11 Feb 2020, Roman Zhuykov wrote:
> > > > 11.02.2020 11:01, Richard
On Wed, Feb 12, 2020 at 11:53:22AM +0100, Richard Biener wrote:
> On Wed, 12 Feb 2020, Segher Boessenkool wrote:
> > On Wed, Feb 12, 2020 at 09:12:58AM +0100, Richard Biener wrote:
> > > On Tue, 11 Feb 2020, Segher Boessenkool wrote:
> > > > Basic block partitioni
On Wed, Feb 12, 2020 at 11:27:01PM +0100, Jakub Jelinek wrote:
> On Mon, Feb 10, 2020 at 01:45:42PM -0500, Michael Meissner wrote:
> > This patch renames the PowerPC internal switch -mprefixed-addr to be
> > -mprefixed.
> This change broke the gcc.target/powerpc/pr93122.c test, so it now
> FAIL: g
On Thu, Feb 13, 2020 at 08:48:33AM +0100, Richard Biener wrote:
> On Wed, 12 Feb 2020, Segher Boessenkool wrote:
> > On Wed, Feb 12, 2020 at 11:53:22AM +0100, Richard Biener wrote:
> > > BB reorder switches back and forth as well ... :/
> >
> > Yes. It is extreme
Hi!
On Thu, Feb 13, 2020 at 04:41:03PM -0600, will schmidt wrote:
> The code generated by this test changed shortly after
> this test was committed, and we didn't get back to
> updating the scan-assembler statements to match.
> Until now.
Progress! :-)
Just some nits:
> [testsuite]
> * gc
On Thu, Feb 13, 2020 at 04:41:09PM -0600, will schmidt wrote:
> Attempting to clean up some more testcase failures.
> This test in particular exercises the -ftree-vectorize
> option, and by inspection I see this fails out with assorted
> "conversion not supported by target" messages on power7 and
From: Matheus Castanho
Some system headers can be broken by the machine_name fix performed
by GCC during the fixincludes step. According to the comment in
fixincludes/fixinc.h:130 :
On some platforms, machine_name doesn't work properly and
breaks some of the header files. Since everything
901 - 1000 of 6106 matches
Mail list logo
