On 06/08/2016 11:31 AM, Jan Hubicka wrote:
I think 20 insns to copy for loop header is way too much. The constant came
from jump.c that was operating with quite different IL and compiler.
This patch adds --param for it so we can fine tune it for new millenia.
+@item max-loop-headers-insns
+The
On 06/08/2016 03:47 AM, Segher Boessenkool wrote:
This patch series introduces separate shrink-wrapping.
[...]
The next six patches are to prevent later passes from mishandling the
epilogue instructions that now appear before the epilogue: mostly, you
cannot do much to instructions with a REG_C
On 06/08/2016 05:16 PM, Segher Boessenkool wrote:
On the plus side I should have caught most of it now. And the failures
are rarely silent, they show up during compilation already.
That does count as a plus. Aborts in dwarf2cfi, I assume.
Most of the problems are code changes the later passe
On 05/20/2016 01:11 AM, Jeff Law wrote:
Let's start with clean up of dead code:
/* We will need to ensure that the address we return is aligned to
REQUIRED_ALIGN. If STACK_DYNAMIC_OFFSET is defined, we don't
always know its final value at this point in the compilation (it
might
On 06/09/2016 02:21 PM, David Edelsohn wrote:
This is a completely unacceptable way to introduce these self-tests.
Please stop adding self-tests that only are tested on x86 Linux and
cause bootstrap failures.
We have no requirement to test patches on more than one target. I think
your request
On 06/15/2016 03:30 AM, Alan Modra wrote:
Between these two calls to _gfortran_string_verify,
if (verify(c4, "A", back = .true.) .ne. 3) call abort
if (verify(c4, "AB") .ne. 0) call abort
it seems that gfortran is assuming that parameters passed on the stack
are unchanged.
How? Is this some
On 06/15/2016 04:03 PM, Alan Modra wrote:
On Wed, Jun 15, 2016 at 11:49:50AM +0200, Bernd Schmidt wrote:
On 06/15/2016 03:30 AM, Alan Modra wrote:
Between these two calls to _gfortran_string_verify,
if (verify(c4, "A", back = .true.) .ne. 3) call abort
if (verify(c4, "AB
This is another step to flesh out -mmitigate-rop for i386 a little more.
The basic idea was (I think) Richard Henderson's: if we could arrange to
have every return preceded by a leave instruction, it would make it
harder to construct an attack since it takes away a certain amount of
control ove
On 06/17/2016 12:37 PM, Jakub Jelinek wrote:
Do you really need to require frame pointer for this?
I mean, couldn't you instead use what you do if a function needs frame
pointer and otherwise just replace the original ret with
pushq %rbp
movq%rsp, %rbp
jmp __rop
On 06/17/2016 04:03 PM, Michael Matz wrote:
But does this really improve something? Essentially you're replacing
0xc9 0xc3
(the end of a function containing "leave;ret") with
0xe9
where the four random bytes are different for each rewritten function
return (but correlated as they di
On 06/17/2016 04:29 PM, Michael Matz wrote:
On Fri, 17 Jun 2016, Bernd Schmidt wrote:
On 06/17/2016 04:03 PM, Michael Matz wrote:
But does this really improve something? Essentially you're replacing
0xc9 0xc3
(the end of a function containing "leave;ret") with
0xe9
On 06/20/2016 02:19 PM, Dominik Vogt wrote:
+/* PR/50938: Check that alloca () reserves the correct amount of stack space.
+ */
Same here really, even if it's only a test.
In this case, the line gets too long with " */" appended.
In that case we wrap before the last word.
Bernd
On 06/20/2016 12:22 PM, tbsaunde+...@tbsaunde.org wrote:
In theory I would expect if anything this helps performance since it isn't
necessary to malloc every time a node is added, however the data is less clear.
Well, we have alloc pools for these lists, so a malloc is not needed for
every nod
On 06/20/2016 02:08 PM, Michael Matz wrote:
P.S: Though I do feel these ROP counter measures are not much more than
security by obscurity; I guess enough obscurity indeed can at least lead
to harder to exploit programs.
I think security by obscurity is the wrong term for this. But I kind of
k
I came across what I think is a bug in cxx_fundamental_alignment_p.
User alignments are specified in units of bytes. This is documented, and
we can also see the following in handle_aligned_attribute, for the case
when we have no args:
align_expr = size_int (ATTRIBUTE_ALIGNED_VALUE / BITS_PER
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
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
=
--- 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
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
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
The problem here is that we don't have complete coverage of lea patterns
for HImode/QImode: the combiner can't recognize a (plus (ashift reg 2)
reg) pattern it builds.
My first idea was to canonicalize ASHIFT by constant inside PLUS to
MULT. The docs say that this is done only inside a MEM con
On 01/16/2017 08:26 PM, Jeff Law wrote:
On 01/13/2017 11:19 AM, Thomas Preudhomme wrote:
Ping? I'm not sure if an ok from Valdimir is enough or if I also need RM
approval.
Vlad's approval is all you need.
Is that a general rule? I'm never too certain on that.
Bernd
On 12/09/2016 12:49 PM, Bernd Schmidt wrote:
On 12/03/2016 10:49 AM, Uros Bizjak wrote:
Based on the above explanation, the patch is OK.
I'll be treating the ifcvt part of it as obvious. However, testing
showed an issue with the i386 funcspec-11 test:
/* PR target/36936 */
/* {
This is essentially the same patch I sent for the previous instance of
this problem, but this time applied to local_cprop_pass. Bootstrapped
and tested on x86_64-linux, and it seems to fix the testcase with a ppc
cross. Ok?
Bernd
PR rtl-optimization/79125
* cprop.c (local_cprop_pass): Handl
The PR is about infinite recursion in combine_simplify_rtx, because
if_then_else_cond does strange things to an expression, and we end up
simplifying something to itself. The patch below tries to address this
by improving that function a little. As stated in the PR, the situation
is that we hav
There's still a a few details that need addressing, and some questions I
have. Also Ccing Jakub to have another pair of eyes on the name of the
section - I don't know if we want some sort of .gnu.something name.
On 01/13/2017 01:19 PM, Torsten Duwe wrote:
2017-01-13 Torsten Duwe :
On 01/24/2017 09:38 AM, Christophe Lyon wrote:
It seems that Bernd's patch causes regressions on arm-linux-gnueabihf
--with-cpu=cortex-a5 --with-fpu=vfpv3-d16-fp16:
gcc.target/arm/vselvcdf.c scan-assembler-times vselvs.f64\td[0-9]+ 1
gcc.target/arm/vselvcsf.c scan-assembler-times vselvs.f32\
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
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 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/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/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 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
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/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_
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
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 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
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 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 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/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
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/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 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/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/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/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 10:27 PM, Jakub Jelinek wrote:
Now successfully bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?
LGTM.
Bernd
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 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 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
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
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
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.
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/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/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
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
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
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
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
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
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
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
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/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
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/05/2016 06:27 AM, Jeff Law wrote:
PR rtl-optimization/69941
* postreload.c (reload_combine_recognize_pattern): Ensure all uses of
the reg share its mode.
testsuite/
PR rtl-optimization/69941
* gcc.dg/torture/pr69941.c: New test.
OK.
For branches as well?
Bernd
This crash happens because LRA tries to save an AVX hard reg in a large
mode, and it only appears in the function in smaller modes. Stack
alignment isn't set up to support the larger mode.
Currently, biggest_mode for hard registers is set up from regno_reg_rtx,
set up to a large mode for argum
This is a case where bogus #line directives can confuse libcpp into
producing nonsensical line numbers, even leading to a crash later on in LTO.
The following patch moves the test earlier to a point where we can more
easily recover from the error condition. I should note that I changed
the raw
On 03/10/2016 10:18 AM, Alan Modra wrote:
Doing the indirect jump optimization turned out to be quite easy.
Bootstrapped and regression tested powerpc64le-linux, gcc-6, gcc-5 and
gcc-4.9. Bootstrap and regression test x86_64-linux still running.
OK to apply?
So much nicer. Ok, and thanks.
B
When I submitted my previous lra-remat patch, I mentioned I had some
concerns about the way we dealt with register number comparisons, but I
didn't want to change things blindly without a testcase. PR70123 has now
provided such a testcase where we are trying to rematerialize a hard
register (r6
On 03/11/2016 04:32 PM, Kyrill Tkachov wrote:
PR driver/70132
* config/arm/driver-arm.c (host_detect_local_cpu): Set file pointer
to NULL after closing file.
Doesn't match the patch. Either variant is fine but please use the right
combination :)
Bernd
On 03/11/2016 11:09 PM, David Malcolm wrote:
+ cpp_error (pfile, CPP_DL_ERROR,
+"file \"%s\" left but not entered", new_file);
Although it looks like you're preserving the existing behavior from
when t
On 03/11/2016 01:55 AM, David Wohlferd wrote:
So, we have been discussing this issue for 4 months now. Over that
time, I have tried to incorporate everyone's feedback.
As a result we have gone from a tiny doc patch (just describe the
current semantics), to a big doc patch (completely deprecate
On 03/14/2016 05:23 PM, Alexander Monakov wrote:
On Mon, 14 Mar 2016, Andrey Belevantsev wrote:
In this case, we get an inconsistency between the sched-deps interface, saying
we can't move an insn writing the si register through a vector insn, and the
liveness analysis, saying we can. The latte
On 03/14/2016 04:38 PM, Segher Boessenkool wrote:
If your machine description refers to a non-existent predicate genrecog
crashes. This fixes it.
Might be better to fix the caller?
Bernd
On 03/14/2016 09:00 PM, Segher Boessenkool wrote:
There is just the single caller, and pred is set right before the call
there. How about this patch, then?
Looks alright.
Bernd
On 03/15/2016 12:14 PM, Jakub Jelinek wrote:
- if (orig_code == LSHIFTRT && result_mode != shift_mode)
+ turn off all the bits that the shift would have turned off.
+ Similarly do this if we've optimized varop so that we don't perform
+ any shift. */
+ if (orig_code == LSHIFTRT
+
On 03/15/2016 03:27 AM, Alan Modra wrote:
On Mon, Mar 14, 2016 at 01:00:39PM -0600, Jeff Law wrote:
Right. Tolerant as in not crash.
So can someone please approve my ira.c:indirect_jump_optimize patch?
I'm not quite audacious enough to claim it is obvious.
Looks good to me.
Bernd
On 03/17/2016 06:23 AM, David Wohlferd wrote:
On 3/14/2016 8:28 AM, Bernd Schmidt wrote:
The example is not good, as discussed previously, and IMO the best
option is to remove it. Otherwise I have no objections to the latest
variant.
Despite the problems I have with the existing sample
On 03/17/2016 06:23 AM, David Wohlferd wrote:
2016-03-16 David Wohlferd
Bernd Schmidt
* doc/extend.texi: Doc basic asm behavior re clobbers.
Any objections from the release managers if I install this for David at
this stage?
Bernd
On 03/17/2016 06:37 PM, Jeff Law wrote:
+ bitmap seen_insns;
+ seen_insns = BITMAP_ALLOC (NULL);
You could save an allocation here by making this a bitmap_head and using
bitmap_initialize.
+ bitmap_set_bit (seen_insns, INSN_UID (insn));
+
if (! INSN_P (insn))
continue
On 03/16/2016 01:22 PM, Jakub Jelinek wrote:
So, this is what we've converged to on IRC and passed bootstrap/regtest
on x86_64-linux and i686-linux. Is this ok for trunk?
The explanation was a bit confusing at first, but I think this looks
reasonable. The assert worries me, but triggering it
On 03/17/2016 12:16 PM, Jakub Jelinek wrote:
Thus, I've reverted the patch (kept the testcase), and after some
discussions on IRC bootstrapped/regtested on x86_64-linux and i686-linux
following version, which right now should change behavior just for the i?86
case and nothing else, so shouldn't
On 03/16/2016 07:45 PM, Jason Merrill wrote:
Discussion of empty class parameter passing ABI led me to notice that
r162402 broke sibcalls with arguments of size 0 in some cases. Before
that commit, the code read
else if ((partial == 0 || args[i].pass_on_stack)
&& size != 0)
{
[...]
On 03/17/2016 04:26 PM, H.J. Lu wrote:
On Thu, Mar 17, 2016 at 8:23 AM, Bernd Schmidt wrote:
On 03/17/2016 04:13 PM, H.J. Lu wrote:
We can add an effective target, something like ignore_pic_pie, and
use it instead of *-*-darwin*.
That should have been done _before_ committing the patch in
On 03/17/2016 04:13 PM, H.J. Lu wrote:
On Thu, Mar 17, 2016 at 8:09 AM, Bernd Schmidt wrote:
On 03/17/2016 04:06 PM, H.J. Lu wrote:
This is the patch I am going to check in.
That still mentions darwin which I imagine might not be an exhaustive test.
We can add an effective target
On 03/17/2016 02:59 PM, H.J. Lu wrote:
On Fri, Mar 11, 2016 at 9:09 AM, H.J. Lu wrote:
We can't set flag_pie to the default when flag_pic == 0, which may be
set by -fno-pic or -fno-PIC, since the default value of flag_pie is
non-zero when GCC is configured with --enable-default-pie. We need
to
On 03/18/2016 08:14 PM, Jeff Law wrote:
I also added a blurb to the dump file when we create these equivalences
and included a test to verify the code fires. I verified it fired on
x86 and x86-64. It may or may not fire on other targets, so I left the
test in the i386 specific subdirectory.
T
This fixes an oversight in my previous patch here. I used biggest_mode
in the assumption that if the reg was used in the function, it would be
set to something other than VOIDmode, but that fails if we have a
multiword access - only the first hard reg gets its biggest_mode
assigned in that case
On 03/17/2016 04:06 PM, H.J. Lu wrote:
This is the patch I am going to check in.
That still mentions darwin which I imagine might not be an exhaustive test.
Bernd
On 03/17/2016 08:17 PM, Richard Henderson wrote:
With -g, and a code section that ends unaligned, the assembler complains of
"unaligned opcodes detected". Except there are no such unaligned opcodes, nor
dwarf2 code ranges covering the end of the section, which arguably makes this
an assembler bu
On 03/21/2016 02:37 AM, Alan Modra wrote:
This series tidies some of the early ira code, in the process making a
tiny improvement to register pressure. Patches 1 to 3 are fairly
simple tidies, with zero impact on generated code. Patch 4 also is
mainly a tidy, but could see some extra REG_EQUIV
Ping.
Bernd
On 03/14/2016 02:20 PM, Bernd Schmidt wrote:
On 03/11/2016 11:09 PM, David Malcolm wrote:
+ cpp_error (pfile, CPP_DL_ERROR,
+ "file \"%s\" left but not entered", new_file);
Al
On 03/21/2016 08:06 PM, Jeff Law wrote:
As noted last week, find_removable_extensions initializes several
bitmaps, but doesn't clear them.
This is not strictly a leak as the GC system should find dead data, but
it's better to go ahead and clear the bitmaps. That releases the
elements back to t
On 03/21/2016 09:15 PM, David Malcolm wrote:
On Mon, 2016-03-14 at 14:20 +0100, Bernd Schmidt wrote:
On 03/11/2016 11:09 PM, David Malcolm wrote:
+ cpp_error (pfile, CPP_DL_ERROR,
+"file \"%s\" left but not ent
On 03/22/2016 10:24 AM, Christophe Lyon wrote:
The ARM test isn't sufficiently protected against non-compliant configurations,
and fails if GCC is configured for arm*linux-gnueabihf for instance
(see
http://people.linaro.org/~christophe.lyon/cross-validation/gcc/trunk/234342/report-build-info.h
On 03/21/2016 02:42 AM, Alan Modra wrote:
* ira.c (combine_and_move_insns): Rather than scanning insns,
use DF infrastucture to find use and def insns.
- remove_death (regno, insn);
This call appears to have gone missing. Is that intentional?
Other than tha
901 - 1000 of 2198 matches
Mail list logo
