On Fri, 13 May 2016, Jakub Sejdak wrote:
> Is it OK for trunk, gcc-4.9, gcc-5 and gcc-6 branches?
It's not appropriate to update these scripts from upstream on release
branches. For example, config.guess changed a while back to output
x86_64-pc-linux-gnu in place of x86_64-unknown-linux-gnu, a
Hello,
when VRP does some transforms, it may create new SSA_NAMEs, but doesn't
give them range information. This can prevent cascading transformations in
a single VRP pass. With this patch, I assign range information to the
variable introduced by one transformation, and in another transformati
OK I understand. So am I right, that in such a case there is no way to
introduce new OS targets to branch 4.9 and 5?
What about 6 branch and trunk?
On the other hand: this is my first patch and I'm not quite familiar
with the procedure of applying patches to upstream. Who should upload
my patch, w
Hello,
maybe this would fit better in VRP, but it is easier (and not completely
useless) to put it in match.pd.
Since the transformation is restricted to GIMPLE, I think I don't need to
check that @0 is SSA_NAME. I didn't test if @0 has pointer type before
calling get_range_info because we a
On 02/16/2016 07:49 PM, Jason Merrill wrote:
Clearly the DR 141 change is requiring much larger adjustments in the
rest of the compiler than I'm comfortable making at this point in the
GCC 6 schedule, so I'm backing out my earlier changes for 10200 and
69753 and replacing them with a more modest
The cse_sincos pass tries to optimize sequences such as
sin (x);
cos (x);
into a single call to sincos, or cexpi, when available. However, the
nvptx target has sin and cos instructions, albeit with some loss of
precision (so it's only enabled with -ffast-math). This patch teaches
cse_sincos p
On May 13, 2016 7:22:37 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>Since a recent change, TYPE_ALIAS_SET of types can change during
>folding.
>This patch arranges for it not to be checksummed.
>
>Bootstrapped/regtested on x86_64-linux and i686-linux (normal
>bootstrap)
>and built (nonbootstrap) +
On May 13, 2016 9:18:57 PM GMT+02:00, Cesar Philippidis
wrote:
>The cse_sincos pass tries to optimize sequences such as
>
> sin (x);
> cos (x);
>
>into a single call to sincos, or cexpi, when available. However, the
>nvptx target has sin and cos instructions, albeit with some loss of
>precision
On Fri, May 13, 2016 at 12:58 PM, Richard Biener
wrote:
> On May 13, 2016 9:18:57 PM GMT+02:00, Cesar Philippidis
> wrote:
>>The cse_sincos pass tries to optimize sequences such as
>>
>> sin (x);
>> cos (x);
>>
>>into a single call to sincos, or cexpi, when available. However, the
>>nvptx targ
On May 13, 2016, at 11:50 AM, Jakub Sejdak wrote:
>
> OK I understand. So am I right, that in such a case there is no way to
> introduce new OS targets to branch 4.9 and 5?
No. You just hand edit in the bits you need for your port, and seek approval
for that.
In general, all new work goes int
On Fri, 2016-05-06 at 12:40 -0400, David Malcolm wrote:
> Mark most virtual functions in gcc/jit as being FINAL OVERRIDE.
> gcc::jit::recording::lvalue::access_as_rvalue is the sole OVERRIDE
> that isn't a FINAL.
>
> Successfully bootstrapped®rtested on x86_64-pc-linux-gnu.
>
> I can self-approve
On Fri, 13 May 2016, Bernd Schmidt wrote:
> Thanks. So, this would seem to suggest that BITS_PER_UNIT in memcmp/memcpy
> expansion is more accurate than a plain 8, although pedantically we might want
> to use CHAR_TYPE_SIZE? Should I adjust my patch to use the latter or leave
> these parts as-is?
This patch by Chris Manghane implements the escape analysis discovery
phase in the Go frontend. Escape analysis is still not turned on.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
On 05/11/2016 09:59 AM, Ilya Verbin wrote:
On Wed, May 11, 2016 at 10:47:49 +0100, Ramana Radhakrishnan wrote:
I've looked at the generated code in more details, and for armv6 this generates
mcr p15, 0, r0, c7, c10, 5
which is not what __cilkrts_fence uses currently (CP15DSB vs CP15DMB)
On Wed, May 11, 2016 at 04:05:46PM -0600, Kelvin Nilsen wrote:
> I have bootstrapped and tested this patch against the trunk and against
> the gcc-6-branch on both powerpc64le-unknown-linux-gnu and
> powerpc64-unknown-linux-gnu with no regressions. Is this ok for trunk
> and for backporting to GCC
The resolution of C11 DR#423, apart from doing things with the types
of expressions cast to qualified types which are only in standard
terms observable with _Generic and which agree with how GCC has
implemented _Generic all along, also specifies that qualifiers are
discarded from function return ty
If the compiled program does a shift by a negative amount, combine will
happily work with that, but it shouldn't then do an undefined operation
in GCC itself. This patch fixes the first case mentioned in the bug
report (I haven't been able to reproduce the second case, on trunk at
least).
Bootstr
This patch adds support for the 32-bit word splat instructions, the byte
immediate splat instructions, and the vector sign extend instructions to GCC
7.0.
In addition to the various splat instructions, since I was modifying the vector
moves, I took the opportunity to reorganize the vector move ins
On Fri, May 13, 2016 at 07:25:43PM -0400, Michael Meissner wrote:
> This patch adds support for the 32-bit word splat instructions, the byte
> immediate splat instructions, and the vector sign extend instructions to GCC
> 7.0.
>
> In addition to the various splat instructions, since I was modifyin
101 - 119 of 119 matches
Mail list logo
