On Wed, Jun 25, 2014 at 10:46 PM, Jeff Law wrote:
> On 06/25/14 02:54, Richard Sandiford wrote:
>>
>> SEQUENCE is just weird though :-) It would be good to have an alternative
>> representation, but that'd be a lot of work on reorg.
>
> Yea. And I don't think anyone is keen on rewriting reorg.
R
On 06/11/14 04:05, Zhenqiang Chen wrote:
On 10 June 2014 19:06, Steven Bosscher wrote:
On Tue, Jun 10, 2014 at 11:22 AM, Zhenqiang Chen wrote:
Hi,
For loop2-invariant pass, when flag_ira_loop_pressure is enabled,
function gain_for_invariant checks the pressures of all register
classes. This d
Hi,
On Wed, Jun 25, 2014 at 03:14:31PM -0600, Jeff Law wrote:
> On 06/24/14 14:19, Martin Jambor wrote:
> >On Mon, Jun 23, 2014 at 03:35:01PM +0200, Bernd Edlinger wrote:
> >>Hi Martin,
> >>
>
> Well actually, I am not sure if we ever wanted to have a race condition
> here.
> Hav
Hi,
the patch below fixes the (I guess now almost infamous) typo that
prints "Type inconsident devirtualization" to the dump. This dumping
has been copied and pasted to a few places so I made all of them just
use the ipa_impossible_devirt_target function to do that. The code
can be consolidated
> Hi,
>
> the patch below fixes the (I guess now almost infamous) typo that
> prints "Type inconsident devirtualization" to the dump. This dumping
> has been copied and pasted to a few places so I made all of them just
> use the ipa_impossible_devirt_target function to do that. The code
> can be
> On Tue, Jun 24, 2014 at 2:53 PM, Jan Hubicka wrote:
>
> > We will also need to introduce ASM_DECLARE_OBJECT_NAME to handle the
> > aliases
> > of variables. I can look into that probably later this week (it is last
> > week
> > of my teaching and I need to do the finals)
>
> varasm.c defau
Hello maintainers:
Please help check this patch when you have time, thanks.
BTW: one linux kernel member found a gcc issue for the latest version
(4.10.0 20140622 or later), but for old version (e.g. 4.10.0 2014060*),
it is OK. It is my chance to fix it (hope can finish within 2014-06-30).
Also
This simplifies some of the test changes in my last patch, I was
misusing the CustomPointerAlloc due to confusion with some uncommitted
changes.
Tested x86_64-linux, committed to trunk.
commit d1a05535e99bfecb427829d3e03ef82e0977e60c
Author: Jonathan Wakely
Date: Wed Jun 25 23:39:20 2014 +01
On Tue, 17 Jun 2014, David Wohlferd wrote:
2014-06-17 David Wohlferd
* doc/extend.texi (Function Attributes): Update 'naked' attribute doc.
This patch makes sense to me and I've seen feedback on an earlier
iteration that lead to this now. So, I am planning to commit this
unless anyo
On Tue, May 20, 2014 at 1:04 PM, Jan Hubicka wrote:
> Hi,
> as disucssed some time ago, our assumption that every symbol of shared
> library can
> be interposed at runtime is expensive and prevents a lot of useful
> optimizations,
> including inlining or IPA propagation.
>
> While this is useful
On 25/06/14 17:50, Jakub Jelinek wrote:
> On Wed, Jun 25, 2014 at 05:21:08PM +1000, Kugan wrote:
>> The problem with SRP_POINTER 0, SRP_SIGNED 1, SRP_UNSIGNED 2,
>> SRP_SIGNED_AND_UNSIGNED 3 (as I understand) is that, it will be
>> incompatible with TYPE_UNSIGNED (tree) and defines of
>> POINTER_EX
Ok, what about the following patch and associated ChangeLog entries?
2014-06-24 Thomas Preud'homme
PR tree-optimization/61375
* tree-ssa-math-opts.c (find_bswap_or_nop_1): Cancel optimization if
symbolic number cannot be represented in an unsigned HOST_WIDE_INT.
Hi,
This bug has nothing to do with negative numbers as in the description.
However, the problem is due to seeking when there are no spaces to skip. I
restructured the loop so that the skipping is not done if there are no spaces.
Regression tested on x86-64. New test case from the PR.
OK for t
> On Tue, May 20, 2014 at 1:04 PM, Jan Hubicka wrote:
> > Hi,
> > as disucssed some time ago, our assumption that every symbol of shared
> > library can
> > be interposed at runtime is expensive and prevents a lot of useful
> > optimizations,
> > including inlining or IPA propagation.
> >
> > Wh
On Wed, Jun 25, 2014 at 6:23 PM, Jan Hubicka wrote:
> We do not need TOC references, but we need to output aliases there and for
> that
> we need to know the declaratoin, so I need to introduce DECLARE_OBJECT_NAME.
> I will look into it either tonight or later this week.
> Thanks for the patch :
On 26/06/14 11:06, Kugan wrote:
> On 25/06/14 17:50, Jakub Jelinek wrote:
>> On Wed, Jun 25, 2014 at 05:21:08PM +1000, Kugan wrote:
>>> The problem with SRP_POINTER 0, SRP_SIGNED 1, SRP_UNSIGNED 2,
>>> SRP_SIGNED_AND_UNSIGNED 3 (as I understand) is that, it will be
>>> incompatible with TYPE_UNSIGN
For example in arm-elf-eabi, movmem need word align, otherwise it will
expand a libcall:
And gcc configure with "--target=arm-elf-eabi --disable-nls
--disable-shared --enable-languages=c,c++ --enable-threads=single
--enable-lto --with-newlib"
test.c:
extern bar(unsigned char p[3][2]);
void foo(in
On 2014-06-25 21:57, Jason Merrill wrote:
OK, thanks.
Do you want me to apply to 4.9 too?
On Wed, 25 Jun 2014, Jakub Jelinek wrote:
Since we've started folding (a << n) | (a >> (bitsize - n)) etc.
into rotates even vectors, we've regressed code quality on targets
where we do have vector shifts, but don't have vector rotates.
The following patch attempts to fix it, by telling veclowe
On Thu, Jun 26, 2014 at 11:06:26AM +1000, Kugan wrote:
> >> Since our aim is to perform single bit checks, why don’t we just use
> >> this representation internally (i.e. _rtx->unchanging = 1 if SRP_SIGNED
> >> and _rtx->volatil = 1 if SRP_UNSIGNED). As for SUBREG_PROMOTED_SIGNED_P,
> >> we still
On Thu, Jun 26, 2014 at 07:43:55AM +0200, Marc Glisse wrote:
> >+ if (compute_type == TREE_TYPE (type)
> >+ && !VECTOR_INTEGER_TYPE_P (TREE_TYPE (rhs2)))
> >+{
> >+ optab oplv, opl, oprv, opr, opo;
> >+ oplv = optab_for_tree_code (LSHIFT_EXPR, type, optab_vec
On June 26, 2014 12:03:21 AM CEST, Martin Jambor wrote:
>Hi,
>
>On Wed, Jun 25, 2014 at 03:14:31PM -0600, Jeff Law wrote:
>> On 06/24/14 14:19, Martin Jambor wrote:
>> >On Mon, Jun 23, 2014 at 03:35:01PM +0200, Bernd Edlinger wrote:
>> >>Hi Martin,
>> >>
>>
>> Well actually, I am not sure
101 - 122 of 122 matches
Mail list logo
