On 4/23/20 8:31 AM, Eric Botcazou wrote:
Thanks, I will take a look at Bernd's work. IIRC, he took a
different approach from what was suggested in the wiki, right?
Yes, let's say that it's a half-baked conversion, probably a consequence of
the bounty. This might be good enough, depending on th
On 3/18/20 3:22 PM, Frank Ch. Eigler via Gcc wrote:
The From: header rewriting for DMARC participants is something sourceware
is doing now.
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? Th
On 1/10/20 8:33 AM, Maxim Kuvyrkov wrote:
Joseph, please point to message on gcc@ mailing list that expresses consensus
of GCC community to use reposurgeon conversion. Otherwise, it is not
appropriate to substitute one's opinion for community consensus.
I was on the fence for a long time, si
On 12/18/19 10:55 PM, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-3a.git
I cloned this one and started trying random things again.
The previous one had some strange-looking merge commits, but it sounded
like that was a known issue, and indeed the ones I had seen wer
On 12/17/19 10:32 PM, Joseph Myers wrote:
git+ssh://gcc.gnu.org/home/gccadmin/gcc-reposurgeon-1a.git
It seems that permission bits are not reproduced entirely correctly. For
example, contrib/check_GNU_style_lib.py went from -rwxr-xr-x in svn (and
the git-svn repository) to -rw-r--r-- in this
On 12/9/19 7:19 PM, Joseph Myers wrote:
For any conversion we're clearly going to need to run various validation
(comparing properties of the converted repository, such as contents at
branch tips, with expected values of those properties based on the SVN
repository) and fix issues shown up by th
On 12/6/19 6:21 PM, Eric S. Raymond wrote:
Your approach sounds pretty reasonable except for that part. I don't
trust git-svn at *all* - I've collided with it too often during
past conversions. It has a nasty habit of leaving damage in places
that are difficult to audit.
So, which steps are w
On 11/28/19 8:53 PM, Gunther Nikl wrote:> Bernd Schmidt
:
>> On 11/23/19 9:53 PM, Bernd Schmidt wrote:
>> move.w %a4,%d0
>> - tst.b %d0
>> - jeq .L352
>> + jeq .L353
>>
>> And the reason - that's a movqi using move.w.
>
On 11/26/19 3:21 AM, Joseph Myers wrote:
>
> The soft-float ColdFire build (--with-arch=cf --with-cpu=54455
> --disable-multilib) successfully built libgcc and glibc, but ran into an
> ICE building the glibc tests. Again, I've not bisected but this commit
> seems likely to be responsible. Com
On 11/26/19 1:36 AM, Joseph Myers wrote:
> I'm seeing a libgcc build failure for coldfire in my build-many-glibcs.py
> bot (m68k-linux-gnu configured --with-arch=cf --disable-multilib). That's
> building _mulsc3.o; I get assembler errors:
I overlooked a difference in the 68881 vs coldfire patte
So I was curious what would happen if I turned on LRA for m68k. It turns
out my autoinc patches from the cc0 patch set expose a bug in how LRA
handles autoincrement. While it copies the logic from reload's
inc_for_reload, it appears to be missing the find_reloads_address code
to ensure an autoinc a
On 11/25/19 1:38 PM, Tobias Burnus wrote:
> Thanks for the m68k work! Can you also update
> https://gcc.gnu.org/backends.html ?
Committed as obvious.
Bernd
commit f42834ad5e77c05cb6bc0908b8fc9282fec7fc19
Author: Bernd Schmidt
Date: Mon Nov 25 13:48:08 2019 +0100
Change backends
On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote:
> Are all 4 + 2 patches in now? Thus, can we close the bug?
We're missing one piece for better autoinc generation, but that's a
small optimization issue. The cc0 conversion is complete.
Bernd
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
After the last fix, I did some more testing and since I feel confident
that it really is in good shape now, I committ
On 11/25/19 12:26 PM, Andreas Schwab wrote:
> On Nov 24 2019, Bernd Schmidt wrote:
>
>> Whew, I think I have it. One tst instruction eliminated when it
>> shouldn't have been:
>>
>> move.w %a4,%d0
>> - tst.b %d0
>> - jeq .L352
>
On 11/24/19 8:43 PM, Segher Boessenkool wrote:
> But. Allowing autoinc into jump insns means those jump insns may then
> eventually need an output reload; it may just have been because of that?
That's almost certainly the reasoning, but as I pointed out in my
original mail - reload is careful aro
On 11/19/19 1:27 AM, Segher Boessenkool wrote:
> The combine parts are okay for trunk, if you keep an eye out :-)
Thanks, now committed. That leaves the auto-inc-dec part. Since we're
being adventurous, I've also bootstrapped and tested the following in
the meantime (on the gcc135 machine). This j
g copy)
@@ -1,3 +1,8 @@
+2019-11-24 Bernd Schmidt
+
+ * config/i386/i386.c (ix86_rtx_costs): Handle care of a PLUS in a
+ COMPARE, representing an overflow detection.
+
2019-11-23 Jan Hubicka
* cif-code.def (MAX_INLINE_INSNS_SINGLE_O2_LIMIT): Remove.
Index: gc
On 11/23/19 9:53 PM, Bernd Schmidt wrote:
> I'll spend a few more days trying to see if I can do something about the
> bootstrap failure Mikael saw (currently trying to do a two-stage cross
> build rather than a really slow bootstrap).
Whew, I think I have it. One tst instruction e
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
In the meantime I've made an aranym setup in addition to the qemu setup
I had, and I've not been able to reproduce fa
On 11/22/19 3:04 PM, Uros Bizjak wrote:
> On Fri, Nov 22, 2019 at 1:58 PM Bernd Schmidt wrote:
>>
>> A patch I posted recently fixes combine to take costs of JUMP_INSNs into
>> account. That causes the pr30315 test to fail with -m32, since the cost
>> of an add that
A patch I posted recently fixes combine to take costs of JUMP_INSNs into
account. That causes the pr30315 test to fail with -m32, since the cost
of an add that sets the flags is estimated too high.
The following seems to fix it. Bootstrapped and tested on x86_64-linux, ok?
Bernd
* config/i386
On 11/22/19 1:42 AM, Segher Boessenkool wrote:
> On Thu, Nov 21, 2019 at 02:36:53PM +0100, Bernd Schmidt wrote:
>> Thanks. Just FYI, this is held up a little. I decided I'd also test on
>> x86, and there it shows a case where ix86_rtx_cost misses something: the
>> i386/p
On 11/21/19 1:30 PM, Matthias Klose wrote:
>
> that would be apt build-dep gcc-9. The former would only install the build
> dependencies of the gcc-defaults package.
That gets me
E: You must put some 'source' URIs in your sources.list
where /etc/apt/sources.list looks like
deb http://ftp.por
On 11/13/19 5:16 PM, Segher Boessenkool wrote:
> On Wed, Nov 13, 2019 at 02:13:48PM +0100, Bernd Schmidt wrote:
>> Also, it does not compute costs for jump
>> insns, so they are always set to zero. As a consequence, any possible
>> substitution is performed if a combination in
On 11/20/19 8:27 PM, Mikael Pettersson wrote:
> On Wed, Nov 20, 2019 at 3:16 PM Bernd Schmidt wrote:
>> Probably best to just run tests on stage1 and hope something shows up.
>
> Ok, how do I did that? I've always just done 'make -k check' after
> full b
On 11/20/19 2:50 PM, Mikael Pettersson wrote:
> On Mon, Nov 18, 2019 at 9:57 PM Mikael Pettersson
> wrote:
>>
>> On Mon, Nov 18, 2019 at 8:31 PM Bernd Schmidt wrote:
>>>
>>> Hi Mikael,
>>>
>>>> This fixed the problem, thanks.
>>>
Hi Mikael,
> This fixed the problem, thanks.
Could you also run the testsuite to see if you can reproduce the
g++.old-deja failures Andreas reported?
Bernd
(Apologies to Jeff who's getting this twice because I didn't hit
reply-all the first time.)
On 11/17/19 6:56 PM, Jeff Law wrote:
> While scanning this patch I did notice the introduction of
> CC_STATUS_INIT in output_{and,ior,xor}si. You might want to check that.
That is intentional. CC_STATUS_
On 11/16/19 9:18 AM, Andreas Schwab wrote:
> On Nov 16 2019, Bernd Schmidt wrote:
>
>> Well, there has to be some difference between what you are doing and
>> what I am doing, because:
>>
>> Running /local/src/egcs/git/gcc/testsuite/g++.old-deja/old-deja.exp ...
>
On 11/15/19 11:50 PM, Andreas Schwab wrote:
> On Nov 15 2019, Bernd Schmidt wrote:
>
>> I meant the compiler command line of course... for any -mcpu flags that
>> might differ from my test run.
>
> There are none.
Well, there has to be some difference between what you
On 11/15/19 10:58 PM, Andreas Schwab wrote:
> On Nov 15 2019, Bernd Schmidt wrote:
>
>> Any chance you could show the command lines from the log files or some
>> other way of reproducing the issue?
>
> Executing on aranym: OMP_NUM_THREADS=2
> LD_LIBRARY_PATH=.:/da
On 11/15/19 5:34 PM, Andreas Schwab wrote:
> On Nov 15 2019, Bernd Schmidt wrote:
>
>> Are these with the patch?
>
> Yes.
>
>> Are you on real hardware
>
> No, I'm using aranym.
Any chance you could show the command lines from the log files or some
other way of reproducing the issue?
Bernd
On 11/15/19 2:48 PM, Andreas Schwab wrote:
> Here are the results of running the testsuite on m68k-linux:
>
> http://gcc.gnu.org/ml/gcc-testresults/2019-11/msg00908.html
>
> This is a list of regressions:
Are these with the patch? I'm not seeing any of these in my testing with
qemu. Are you on r
On 11/13/19 9:03 PM, Jeff Law wrote:
> OK. I'd actually recommend this go ahead and get installed. My tester
> will bootstrap it overnight.
Alright, let me know how that turns out. What kind of machine do you
have for that?
Bernd
On 11/13/19 7:16 PM, Segher Boessenkool wrote:
> I tried this out with a kernel build (just the defconfig).
> during RTL pass: jump2
> /home/segher/src/kernel/fs/binfmt_elf.c: In function 'elf_core_dump':
> /home/segher/src/kernel/fs/binfmt_elf.c:2409:1: internal compiler error: in
> patch_jump_i
After the m68k cc0 conversion, there is one code quality regression that
I can see: we no longer generate autoinc addressing modes in
comparisons. This is because the parts of the compiler that generate
autoinc are unwilling to substitute into jumps.
If you look at the code in reload, you'll see t
The combiner is somewhat strange about how it uses costs. If any of the
insns involved in a comparison have a cost of 0, it does not verify that
the substitution is cheaper. Also, it does not compute costs for jump
insns, so they are always set to zero. As a consequence, any possible
substitution i
This achieves the conversion by using combined cbranch/cstore patterns,
and using a mechanism similar to the cc_status tracking to elide certain
comparisons. Unlike cc_status, this is opt-in and requires a
flags_valid attribute to be set for suitable instructions. Due to lack
of test hardware, th
This tidies up a few spots in the m68k backend in preparation for the
large patch to follow. This is purely for review purposes: this patch
has not been tested independently, and will be committed together with
the following one.
Noteworthy changes:
Some patterns and peepholes were unified throu
This is a set of patches to convert m68k so that it no longer uses cc0.
The approach is to combine cc0 setter/user pairs into cbranch and cstore
patterns. It does not expose the flag register directly. Since m68k is a
target that is not under active development, and probably receives very
limited t
https://bugs.kde.org/show_bug.cgi?id=412482
Bug ID: 412482
Summary: Patch to fix crashes involving piece holders
Product: palapeli
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity:
Hi all,
I am currently using the Java CAS Client for Jira integration, version
3.5.1-SNAPSHOT ("java-cas-client/cas-client-integration-atlassian" from
https://github.com/apereo/java-cas-client/tree/master/cas-client-integration-atlassian)
and encounter the following effect.
In case there is n
On 07/09/2018 09:19 PM, Eric S. Raymond wrote:
> Last time I did a comparison between SVN head and the git conversion
> tip they matched exactly. This time I have mismatches in the following
> files.
So what are the diffs? Are we talking about small differences (like one
change missing) or large-
On 05/15/2018 12:58 PM, A. Skrobov wrote:
>>> That makes me wonder if there is a latent bug though. Consider pushing
>>> args to a pure function. Could we then try to CSE the memory reference
>>> and get it wrong because we haven't accounted for the autoinc?
>>
>> Can't know for sure but one woul
On 05/14/2018 10:55 PM, Jeff Law wrote:
> That does sound vaguely familiar. Did we put autoinc notes on the stack
> pushes?
Not as far as I recall. I only see REG_ARGS_SIZE notes in the dumps.
> That makes me wonder if there is a latent bug though. Consider pushing
> args to a pure function. C
On 05/12/2018 07:01 PM, Jeff Law wrote:
> No. We're not supposed to have any auto-inc insns prior to the auto-inc
> pass. A stack push/pop early in the compiler would have to be
> represented by a PARALLEL.
>
> It's been this way forever. It's documented in the internals manual
> somewhere.
S
Thanks for all the infos.
That helps so far to understand the issue .
Cheers, Bernd
Mit freundlichen Grüßen
Bernd Schmidt
SOFTWARE-ENTWICKLUNG
b.schm...@eggheads.de
Von: Shawn Heisey
An:
Gesendet: 07.12.2017 19:00
Betreff: Re: Howto search for § character
On 12/7
field!
What is your recommended way to deal with it?
Is it possible to remove the word break behaviour for the § char?
Or is the best way to encode all § chars when indexing and searching?
Thanks, Bernd
Mit freundlichen Grüßen
Bernd Schmidt
SOFTWARE-ENTWICKLUNG
b.schm...@eggheads
s where
entityClass:StructureNodeImpl)
q=_text_:§ => numFound:0
How can we search for the occurence of the § character?
Best regards,
Bernd
Mit freundlichen Grüßen
Bernd Schmidt
SOFTWARE-ENTWICKLUNG
b.schm...@eggheads.de
eggheads GmbH
Herner Straße 370
44807 Bochum
On 08/27/2017 09:36 PM, Jon Beniston wrote:
> I have an out-of-tree GCC port and it is struggling supporting
> auto-vectorization on some dot product instructions. For example, I have an
> instruction that takes three operands which are all 32-bit general
> registers. The second and third operands
On 07/10/2017 05:10 PM, Georg-Johann Lay wrote:
> (set (zero_extract:QI (reg/i:QI 24 r24)
> (const_int 1 [0x1])
> (const_int 6 [0x6]))
> (lshiftrt:QI (reg:QI 52)
> (const_int 6 [0x6])))
> The problem is that the backend only sees
>
> avr_rtx_costs[bset:combine(266)]=tr
On 06/11/2017 08:03 PM, Gerald Pfeifer wrote:
> On Tue, 30 May 2017, Bernd Schmidt wrote:
>> On 05/30/2017 09:05 AM, Richard Biener wrote:
>>> This leaves the nvptx and c6x ports without a maintainer. Do
>>> you have any recommendations for a successor here?
>> N
On 05/30/2017 09:05 AM, Richard Biener wrote:
> This leaves the nvptx and c6x ports without a maintainer. Do you have
> any recommendations for a successor here?
Not really. It would be a shame to lose the C6X port though. If I'm CC'd
on any bug reports I'm prepared to keep it working - if that's
On 05/27/2017 12:52 PM, Bernd Schmidt wrote:
I am no longer working for Red Hat, so I've updated my email address.
Also, I don't expect to be around very much in the near future, so I've
removed myself as maintainer for some areas.
Judging by a reply I got, I may have been too
=
--- ChangeLog (revision 248535)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2017-05-27 Bernd Schmidt
+
+ * MAINTAINERS: Update my email address, and remove myself as
+ maintainer in some areas.
+
2017-05-25 Eric Gallager
* MAINTAINERS: Add self to Write After Approval
Ind
If you look at certain testcases like the one for PR78972, you'll find
that the code generated by TER is maximally pessimal in terms of
register pressure: we can generate a large number of intermediate
results, and defer all the statements that use them up.
Another observation one can make is
On 03/27/2017 12:56 PM, Alexander Monakov wrote:
Hello Bernd,
Can you have a look at this patch (unchanged from previous posting in January)?
The rest of the patches in the set are reviewed.
On Wed, 22 Mar 2017, Alexander Monakov wrote:
This patch adds handling of new omp_simt_enter/omp_simt_
geLog (revision 246472)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2017-03-25 Bernd Schmidt
+
+ PR rtl-optimization/80160
+ PR rtl-optimization/80159
+ * lra-assigns.c (must_not_spill_p): Tighten new test to also take
+ reg_alternate_class into account.
+
2017-03-24 Vladimir Makarov
PR t
On 03/22/2017 04:38 PM, Uros Bizjak wrote:
LGTM, but I don't want to step on Bernd's toes, so let's wait for his opinion.
I was waiting for yours really, that's the one that counts.
Bernd
On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
r246227
Can you help narrow that down?
Bernd
On 03/15/2017 09:59 PM, Segher Boessenkool wrote:
This testcase can only ever be built on x86 (it needs the "avx*"
attributes). This patch skips the test elsewhere.
Is this okay for trunk?
Ok.
Bernd
On 03/16/2017 01:31 PM, Markus Trippelsdorf wrote:
clang --analyze pointed out a number of dead stores and initializations.
Tested on ppc64le. Ok for trunk?
I'd say - not now.
Ideally someone would delve into the commit history to figure out what
happened with each of these, and whether any
I suggest we apply the following and close the PR as INVALID (not a
bug). Ok?
Bernd
Index: pr65693.c
===
--- pr65693.c (revision 245685)
+++ pr65693.c (working copy)
@@ -2,6 +2,11 @@
/* { dg-do compile } */
/* { dg-options "
On 03/15/2017 04:00 PM, Bernd Schmidt wrote:
On 03/15/2017 12:09 AM, Bernd Schmidt wrote:
I'll retest with your
suggestion and with the bitmap creation conditional on i1 being nonnull.
Like this (also had to throw in a bitmap_empty_p). Retested as before. Ok?
Oops, that one als
On 03/15/2017 12:09 AM, Bernd Schmidt wrote:
I'll retest with your
suggestion and with the bitmap creation conditional on i1 being nonnull.
Like this (also had to throw in a bitmap_empty_p). Retested as before. Ok?
Bernd
Index: gcc/comb
This fixes a failure in the testsuite. When we transform the doloop
pattern, the decrement of the old iteration register goes away, which is
a problem if it's used after the loop (where it should have the value zero).
Committed.
Bernd
* config/c6x/c6x.c (predicate_insn): Avoid rtl sharing fa
This triggered a kernel miscompilation with an old (4.8 I think) aarch64
toolchain.
Here's the reloads for the insn where things go wrong:
Reloads for insn # 210
Reload 0: reload_in (DI) = (reg/v/f:DI 80 [ pgdata ])
GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 0)
reload_in_re
On 03/15/2017 12:03 AM, Jeff Law wrote:
On 03/10/2017 04:24 PM, Bernd Schmidt wrote:
PR rtl-optimization/79910
* combine.c (record_used_regs): New static function.
(try_combine): Handle situations where there is an additional
instruction between I2 and I3 which needs to have a
In this PR, we have a few insns involved in two instruction combinations:
insn 16: set r100
insn 27: some calculation
insn 28: some calculation
insn 32: using r100
insn 33: using r100
insn 35: some calculation
Then we combine insns 27, 28 and 33, producing two output insns, As a
result, insn 28
Ping (minus the require-effective-target line, as Uros pointed out).
Bernd
On 03/03/2017 02:51 PM, Bernd Schmidt wrote:
This is an ICE where setup_pressure_classes fails if xmm0 is a global
reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only
SSE_FIRST_REG as the third register class
On 03/10/2017 08:03 PM, David Malcolm wrote:
print-rtl.c:rtx_writer::print_rtx_operand_code_0 has some special
-casing for SYMBOL_REF, but if I'm reading things right we don't yet
dump SYMBOL_REF_BLOCK and SYMBOL_REF_BLOCK_OFFSET, so we'd need to dump
these somehow.
Yeah. Perhaps as an extra ta
On 03/10/2017 06:53 PM, Jakub Jelinek wrote:
+
+template
+static inline rtx
+ix86_delegitimize_address_tmpl (rtx x)
{
Why is this a template and not a function arg?
Bernd
On 03/09/2017 08:28 PM, David Malcolm wrote:
The root cause is an out-of-bounds memory write in the RTL dump
reader when handling SYMBOL_REFs with SYMBOL_FLAG_HAS_BLOCK_INFO set.
Such SYMBOL_REFs are normally created by varasm.c:create_block_symbol,
which has:
Hmm, I don't actually recall seei
On 03/03/2017 02:33 PM, Marek Polacek wrote:
2017-03-03 Marek Polacek
PR c/79758
* c-decl.c (store_parm_decls_oldstyle): Check if the element of
current_function_prototype_arg_types is error_mark_node. Fix
formatting. Use TREE_VALUE instead of TREE_TYPE.
This is an ICE where setup_pressure_classes fails if xmm0 is a global
reg. Instead of GENERAL/FLOAT/SSE/MMX_REGS, it computes only
SSE_FIRST_REG as the third register class. The problem is that the costs
for moving between SSE_FIRST_REG and SSE_REGS are inflated because we
think we have no avai
In this PR, we have an endless cycle in LRA, generating ever more
instructions. The relevant portions of the dump seem to be these:
** Local #9: **
Creating newreg=130 from oldreg=128, assigning class CREG to r130
18:
{r117:DI=unspec/v[[r129:SI*0x8+r123:SI],r117:DI,r122
On 03/02/2017 06:50 PM, Martin Liška wrote:
Hello.
This is second part of fixes needed to not trigger integer overflow in gcse
pass.
So, how is this intended to work? The min/max stored in the param is an
int, and by using a HOST_WIDE_INT here, we expect that it is a larger
type and therefo
On 03/02/2017 06:35 PM, Marek Polacek wrote:
While at it, I fixed wrong formatting in the nearby code. Also use NULL_TREE
instead of 0 where appropriate. I really dislike those zeros-as-trees; one
day I'll just go and turn them into NULL_TREEs.
I sympathize, but it makes it harder to see whic
On 03/02/2017 10:23 AM, Jakub Jelinek wrote:
2017-03-02 Jakub Jelinek
PR rtl-optimization/79780
* cprop.c (one_cprop_pass): When second and further conditional trap
in a single basic block is turned into an unconditional trap, turn it
into a deleted note to avo
On 02/23/2017 10:27 PM, Jakub Jelinek wrote:
Now successfully bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?
LGTM.
Bernd
On 02/23/2017 02:36 PM, Jakub Jelinek wrote:
and both UNLT and GE can be reversed. But if the arguments of the condition
are canonicalized, we run into:
/* Test for an integer condition, or a floating-point comparison
in which NaNs can be ignored. */
if (CONST_INT_P (arg0)
|| (GE
On 02/23/2017 12:46 PM, Jakub Jelinek wrote:
But as soon as we only have the (unlt (reg:DF 100) (reg:DF 97)),
reversed_comparison_code fails on it:
case UNLT:
case UNLE:
case UNGT:
case UNGE:
/* We don't have safe way to reverse these yet. */
return UNKNOWN;
I do ha
On 02/21/2017 03:48 PM, Segher Boessenkool wrote:
2017-02-21 Segher Boessenkool
* config/c6x/c6x.c (predicate_insn): Do not incorrectly share RTL.
Ok, thanks.
Bernd
On 02/17/2017 10:11 AM, Richard Biener wrote:
Index: gcc/fwprop.c
===
--- gcc/fwprop.c(revision 245501)
+++ gcc/fwprop.c(working copy)
@@ -1478,7 +1478,8 @@ fwprop (void)
Do not forward propagate addresses into
On 02/17/2017 02:09 PM, Thomas Schwinge wrote:
Hi!
On Fri, 17 Feb 2017 14:00:09 +0100, I wrote:
[...] for "normal" functions there is no reason to use the
".param" space for passing arguments in and out of functions. We can
then get rid of the boilerplate code to move ".param %in_ar*" into ".r
On 02/17/2017 02:09 PM, Thomas Schwinge wrote:
Hi!
On Fri, 17 Feb 2017 14:00:09 +0100, I wrote:
[...] for "normal" functions there is no reason to use the
".param" space for passing arguments in and out of functions. We can
then get rid of the boilerplate code to move ".param %in_ar*" into ".r
We have two registers being assigned to each other:
(set (reg 213) (reg 209))
(set (reg 209) (reg 213))
These being the only definitions, we are happy to forward propagate reg
209 for reg 213 into a third insn, making a new use for reg 209. We are
then happy to forward propagate reg 213 for
On 02/15/2017 12:49 PM, Marek Polacek wrote:
We ICEd on this testcase in do_warn_double_promotion because an invalid
conversion had produced an error result type and accessing that via
TYPE_MAIN_VARIANT crashes. Fixed in an obvious way.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
201
On 02/13/2017 02:06 PM, Martin Liška wrote:
On 02/13/2017 01:58 PM, Bernd Schmidt wrote:
On 02/13/2017 11:15 AM, Martin Liška wrote:
In order to not cause a stack overflow, lets use a vector allocated on heap
instead of
the one created by XALLOCVEC.
Patch can bootstrap on ppc64le-redhat
On 02/10/2017 08:50 PM, Jakub Jelinek wrote:
2017-02-10 Jakub Jelinek
PR rtl-optimization/79388
PR rtl-optimization/79450
* combine.c (distribute_notes): When removing TEM_INSN for which
corresponding dest has last value recorded, invalidate that last
On 02/13/2017 11:15 AM, Martin Liška wrote:
In order to not cause a stack overflow, lets use a vector allocated on heap
instead of
the one created by XALLOCVEC.
Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
Ok. I'm surprised this is marked as a regression, but it'
On 01/27/2017 01:02 PM, Eric Botcazou wrote:
The attached
patch is a middle ground between the previously working and currently broken
situations: if the back-end defines STACK_DYNAMIC_OFFSET, then the middle-end
assumes that STACK_DYNAMIC_OFFSET maintains the alignment; if it doesn't,
which mean
This PR seems to be curable by fixing up the CFG a little earlier.
Bootstrapped and tested on x86_64-linux, and it seems to cure the
testcase with a ppc cross. I'd appreciate if someone ran full ppc tests
with this though. Ok?
Bernd
PR rtl-optimization/79194
* cprop.c (one_cprop_pass): Move
On 01/27/2017 02:19 AM, Segher Boessenkool wrote:
But what is "insn cost"? Latency is no good at all -- we *want* insns
with higher latency to be earlier. fsqrt is not pipelined, and that is
what makes it so costly. (This isn't modeled in the scheduling
description btw: that would make the au
On 01/25/2017 08:46 PM, Segher Boessenkool wrote:
It turns out my patch (see the PR) causes (or at least triggers)
miscompilations on tilegx. I will drop it for now.
Curious, it looked very reasonable. What's needed to reproduce this?
Bernd
On 01/25/2017 10:18 AM, Kyrill Tkachov wrote:
The test is supposed to test the generation of the vsel instruction.
I believe adding an -mcpu=cortex-a57 to the testcases would be best, as
VSEL isn't actually available on Cortex-A5, it's just enabled by the
-mfpu=fp-armv8 option.
A more realistic c
On 01/24/2017 06:03 PM, Christophe Lyon wrote:
Ha... the regression occurred between r 244818 and r 244816,
and I read r 244816 ChangeLog too quickly and did not notice
it was modifying ifcvt.c in addition to x86-only files.
So it's likely that it's your other patch for pr78634
that caused the
On 01/24/2017 05:50 PM, Kyrill Tkachov wrote:
Actually trying it out with an explicit -mcpu=cortex-a5 (so -O2 -S
-mfpu=fp-armv8 -mcpu=cortex-a57 -mfloat-abi=hard) I get
the test failing before and after the patch. The code generated is
vcmp.f64d0, d1
vmrsAPSR_nzcv, FP
On 01/24/2017 05:30 PM, Kyrill Tkachov wrote:
The -mfpu is overridden in the testcase to add the ARMv8 instructions.
So to reproduce the compilation in that testcase you'd want
-mfpu=fp-armv8 or
something equivalent rather than vfpv3-d16-fp16.
Exact steps please. No one who's not well-versed i
1 - 100 of 3062 matches
Mail list logo
