On Thu, Aug 4, 2011 at 4:05 PM, Mike Hommey wrote:
> Hi,
>
> We (Mozilla) are trying to get the best of the ARM toolchain for our
> Android build. I recently built an Android Native-code Development Kit
> with GCC 4.6.1 and binutils 2.21.53, instead of GCC 4.4.3 and binutils
> 2.19 that come with
On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
>>> Did you try using FDO with -Os? FDO should make hot code parts
>>> optimized similar to -O3 but leave other pieces optimized for size.
>>> Using FDO with -O3 gives you the opposite, cold portions optimized
>>> for size while the rest is optim
On Sat, Aug 6, 2011 at 5:00 PM, Paolo Bonzini wrote:
> On 08/04/2011 01:10 PM, Andrew Haley wrote:
>> It's the sort of thing that gets done in threaded interpreters,
>> where you really need to keep a few pointers in registers and
>> the interpreter itself is a very long fun
On Wed, Aug 10, 2011 at 12:29 PM, Paulo J. Matos wrote:
> Hi,
>
> I am having a size optimisation issue with GCC-4.6.1.
> The problem boils down to the fact that I have no idea on the best way to
> hint to GCC that a given insn would make more sense someplace else.
>
> The C code is simple:
> int1
On Wed, Aug 10, 2011 at 1:40 PM, Richard Guenther
wrote:
> On Wed, Aug 10, 2011 at 12:29 PM, Paulo J. Matos
> wrote:
>> Hi,
>>
>> I am having a size optimisation issue with GCC-4.6.1.
>> The problem boils down to the fact that I have no idea on the best way to
&g
On Wed, Aug 10, 2011 at 3:46 PM, Paulo J. Matos wrote:
> On 10/08/11 12:40, Richard Guenther wrote:
>>
>> On x86 we expand the code to ((xl& al) ^ al) | ((xh& ah) ^ ah) == 0
>> which is then if-converted. Modified testcase:
>>
>> long long x;
>&g
On Thu, Aug 11, 2011 at 10:11 AM, Paulo J. Matos wrote:
> On Thu, Aug 11, 2011 at 1:01 AM, Vladimir Makarov wrote:
>> I can not reproduce the problem. It would be nice to give all info (the
>> code without includes and all options). In this case I could have more info
>> to say more definitely
On Thu, Aug 11, 2011 at 5:15 PM, Florian Merz wrote:
> Dear gcc developers,
>
> this is about an issue that popped up in a verification project [1] based on
> LLVM, but it seems to be already present in the gimple code, before llvm-gcc
> transforms the gimple code to LLVM-IR.
>
> In short:
> Calcu
ursday, 11. August 2011, 17:48:26 schrieb Richard Guenther:
>> On Thu, Aug 11, 2011 at 5:15 PM, Florian Merz wrote:
>> > Dear gcc developers,
>> >
>> > this is about an issue that popped up in a verification project [1] based
>> > on LLVM, but it seems to be alr
On Thu, Aug 11, 2011 at 7:13 PM, Joe Buck wrote:
> On Thu, Aug 11, 2011 at 09:05:19AM -0700, Florian Merz wrote:
>> If I remember the standard correctly, pointer subtraction is valid if both
>> pointers point to elements of the same array or to one past the last element
>> of the array. According
On Thu, Aug 11, 2011 at 10:36 PM, Joe Buck wrote:
> On Thu, Aug 11, 2011 at 1:58 PM, Joseph S. Myers
> wrote:
>> -ftrapv and -fwrapv should have no effect on pointer subtraction.
>
> Gaby writes:
>
>> Yes!
>
> Wouldn't it suffice to convert the pointers to unsigned, do an unsigned
> subtraction
On Fri, Aug 12, 2011 at 11:48 AM, Rohit Arul Raj wrote:
> On Fri, Aug 12, 2011 at 12:17 PM, Rohit Arul Raj
> wrote:
>> Hello All,
>>
>> I am working on 32-bit target with gcc 4.6.0. I need some help on the
>> following:
>>
>> For my target, If my CCR register is set, all the arithmetic
>> instr
On Mon, Aug 15, 2011 at 2:16 PM, 王亮 wrote:
> Hi,
>
> Current implementation of ggc_alloc_rtvec_sized is
>
> #define ggc_alloc_rtvec_sized(NELT) \
> (ggc_alloc_zone_vec_rtvec_def (sizeof (rtx), \
> sizeo
s broken we have to invent a fix in the middle-end
and (conditionally) guard any libcall block moves.
Comments? Ok to commit?
Thanks,
Richard.
2011-08-15 Richard Guenther
PR middle-end/50079
* g++.dg/init/copy7.C: Remove testc
On Tue, Aug 16, 2011 at 10:37 PM, Sriraman Tallam wrote:
> Hi,
>
> I am working on supporting function multi-versioning in GCC and here
> is a write-up on its usability.
>
> Multiversioning Usability
>
>
> For a simple motivating example,
>
> int
> find_popcount(unsigned int
e on various use cases which has been carefully thought out.
> Please be specific on which part needs to improvement.
See below ...
> Thanks,
>
> David
>
> On Wed, Aug 17, 2011 at 12:29 AM, Richard Guenther
> wrote:
>> On Tue, Aug 16, 2011 at 10:37 PM, Sriraman Tallam
On Wed, Aug 17, 2011 at 6:37 PM, Xinliang David Li wrote:
> On Wed, Aug 17, 2011 at 8:12 AM, Richard Guenther
> wrote:
>> On Wed, Aug 17, 2011 at 4:52 PM, Xinliang David Li
>> wrote:
>>> The gist of previous discussion is to use function overloading instead
On Thu, Aug 18, 2011 at 11:34 AM, Gerald Pfeifer wrote:
> On Tue, 2 Aug 2011, Jakub Jelinek wrote:
>>> Revisions 176335 removed the traditional "#include " from
>>> gthr-posix.h. This breaks the build of many programs (Firefox, Chromium,
>>> etc.) that implicitly rely on it.
>> This isn't the firs
On Mon, Aug 22, 2011 at 10:19 AM, Richard Sandiford
wrote:
> Georg-Johann Lay writes:
IMO a clean approach would be to query the costs of a whole insn (resp.
it's pattern) rather than the cost of an RTX. COSTS_N_INSNS already
indicates that the costs are compared to *insn* costs i.e.
On Fri, Aug 26, 2011 at 2:52 PM, Vladimir Yakovlev wrote:
> Hi,
>
> Following test fails in linking if compiled with ffast-math and O0,
> but it compiled successfully with ffast-math and O2. Also no problem
> if -lm is added.
>
> $ cat t.c
> #include
>
> float foo(float x)
> {
> float y = 0;
>
On Sat, Aug 27, 2011 at 4:47 AM, Matt Davis wrote:
> Hello,
> I am having the compiler insert a call to a function which is defined inside
> another object file. However, during inline expansion via
> expand_call_inline(),
> the following assertion fails in tree-inline.c:
>>> 3775: edge = cgraph
On Sat, Aug 27, 2011 at 10:06 AM, Matt Davis wrote:
> On Sat, Aug 27, 2011 at 09:27:49AM +0200, Richard Guenther wrote:
>> On Sat, Aug 27, 2011 at 4:47 AM, Matt Davis wrote:
>> > Hello,
>> > I am having the compiler insert a call to a function which is defined
>
On Sun, Aug 28, 2011 at 1:30 AM, Matt Davis wrote:
> On Sat, Aug 27, 2011 at 11:25:45AM +0200, Richard Guenther wrote:
>> On Sat, Aug 27, 2011 at 10:06 AM, Matt Davis wrote:
>> > On Sat, Aug 27, 2011 at 09:27:49AM +0200, Richard Guenther wrote:
>> >> On Sat, Aug 2
On Wed, Aug 31, 2011 at 4:24 PM, Basile Starynkevitch
wrote:
> Hello Folks
>
> What is the intended role of the dump_file [the one known in tree-pass.h
> near line 101] for plugins?
>
> May plugins print their arbitrary things (e.g. their own debug printing)
> inside? I believe that yea, but I am
On Fri, Sep 2, 2011 at 7:58 AM, Jiangning Liu wrote:
> Hi,
>
> For the following small case,
>
> int f(int i, int j)
> {
> if (i==1 && j==2)
> return i;
> else
> return j;
> }
>
> with -O2 option, GCC has vrp2 dump like below,
>
> ==
On Sun, Sep 4, 2011 at 10:47 AM, Tobias Burnus wrote:
> Hi,
>
> Fortran 2008 has a do concurrent construct, where the programmer guarantees
> that the result is independent of the order; e.g.
> do concurrent (i = 1:10:2) ! from, to, step/stride
> A(i) = sin(B(i))
> end do
> can be run as i
On Mon, Sep 5, 2011 at 9:50 AM, Romain Geissler
wrote:
> Hi
>
> Is there any particular reason to load plugin with the RTLD_NOW option?
> This option force .so symbol resolution to be completely made at load time,
> but this could be done only when a symbol is needed (RTLD_NOW).
>
> Here is the dl
On Tue, Sep 6, 2011 at 5:30 PM, Bingfeng Mei wrote:
> Hi,
> I compile the following code with arm gcc 4.6 (x86 is the similar with one of
> 4.7 snapshot).
> I noticed "a" is written to memory three times instead of being added by 3
> and written at the
> end. Doesn't restrict guarantee "a" won't
On Wed, Sep 7, 2011 at 6:23 PM, Vladimir Makarov wrote:
> On 09/07/2011 11:55 AM, Xinliang David Li wrote:
>>
>> Why is lto/whole program mode not used in LLVM for peak performance
>> comparison? (of course, peak performance should really use FDO..)
>>
> Thanks for the feedback. I did not manage
On Wed, Sep 7, 2011 at 5:28 PM, Diego Novillo wrote:
> One of the most vexing aspects of GCC development is dealing with
> failures in the various testsuites. In general, we are unable to
> keep failures down to zero. We tolerate some failures and tell
> people to "compare your build against a c
On Thu, Sep 8, 2011 at 12:31 AM, Steve White
wrote:
> Hi,
>
> I run some tests of simple number-crunching loops whenever new
> architectures and compilers arise.
>
> These tests on recent Intel architectures show similar performance
> between gcc and icc compilers, at full optimization.
>
> Howeve
On Thu, Sep 8, 2011 at 1:04 PM, Diego Novillo wrote:
> On Thu, Sep 8, 2011 at 04:31, Richard Guenther
> wrote:
>
>> I think it would be more useful to have a script parse gcc-testresults@
>> postings from the various autotesters and produce a nice webpage
>> with revis
On Thu, Sep 8, 2011 at 1:33 PM, Diego Novillo wrote:
> On Thu, Sep 8, 2011 at 07:16, Richard Guenther
> wrote:
>
>> Well, you'd need to maintain a list of known XPASS/FAILs anyway.
>
> Yes, of course. That's the manifest of things you expect to be broken.
&g
On Thu, Sep 8, 2011 at 2:14 PM, Diego Novillo wrote:
> On Thu, Sep 8, 2011 at 07:49, Richard Guenther
> wrote:
>
>> Well, I'd rather _fix_ dejagnu then. Any specific example you can't
>> eventually xfail by dg-skipping the testcase?
>
> Several I mentione
On Thu, Sep 8, 2011 at 2:26 PM, Diego Novillo wrote:
> On Thu, Sep 8, 2011 at 08:20, Richard Guenther
> wrote:
>
>> Cache the comparison result? If you specify a (minimum) revision
>> required for testing just test against a cached revision that fulfils
>> the requ
On Thu, Sep 8, 2011 at 3:09 PM, Steve White wrote:
> Hi Richard!
>
> On Thu, Sep 8, 2011 at 11:02 AM, Richard Guenther
> wrote:
>> On Thu, Sep 8, 2011 at 12:31 AM, Steve White
>> wrote:
>>> Hi,
>>>
>>> I run some tests of simple number
On Thu, Sep 8, 2011 at 3:20 PM, Richard Guenther
wrote:
> On Thu, Sep 8, 2011 at 3:09 PM, Steve White
> wrote:
>> Hi Richard!
>>
>> On Thu, Sep 8, 2011 at 11:02 AM, Richard Guenther
>> wrote:
>>> On Thu, Sep 8, 2011 at 12:31 AM, Steve White
>>>
On Fri, Sep 9, 2011 at 9:09 AM, Jakub Jelinek wrote:
> Status
> ==
>
> The trunk is in Stage 1, which, if we follow roughly the 4.6
> release schedule, should end around end of October.
> At this point I'd like to gather the status of the various
> development branches that haven't been merged
On Wed, Sep 21, 2011 at 4:57 PM, Paulo J. Matos wrote:
> On 21/09/11 15:21, David Brown wrote:
>>
>> And since this
>> situation would not occur in real code (at least, not code that is
>> expected to do something useful other than test the compiler's code
>> generation), there is no harm in makin
On Mon, Sep 12, 2011 at 10:10 AM, pavan tc wrote:
> Hi,
>
> I would like to know if there have been issues with optimized linked
> list code with GCC 4.3.2. [optiimization flag : -O2]
>
> The following is the inlined code that has the problem:
>
> static inline void
> list_add_tail (struct list_he
$1, %eax
> jne .L14
>
> * With PRE,
>
> Path1:
> movl $1, %ebx
> movl $2, %eax
> testb %bl, %bl
> je .L3
>
> Path2:
> movl $1, %ebx
> movb $3, %al
> testb %bl, %bl
>
On Thu, Sep 15, 2011 at 6:26 PM, Paolo Bonzini wrote:
> On 09/15/2011 06:19 PM, Richard Henderson wrote:
>>
>> I wouldn't go that far. They *used* to be compiler barriers,
>> but clearly something broke at some point without anyone noticing.
>> We don't know how many versions are affected until w
On Fri, Sep 23, 2011 at 6:42 PM, Bingfeng Mei wrote:
> Hi,
> I notice the following description is different from how spu & m32c use it.
>
> In internal manual:
>
> bool TARGET_ADDR_SPACE_SUBSET_P (addr space t superset, [Target Hook]
> addr space t subset)
> Define this to return whether the subs
On Mon, Sep 26, 2011 at 9:39 AM, Jiangning Liu wrote:
>> > * Without PRE,
>> >
>> > Path1:
>> > movl $2, %eax
>> > cmpl $1, %eax
>> > je .L3
>> >
>> > Path2:
>> > movb $3, %al
>> > cmpl $1, %eax
>> > je .L3
>> >
>> > Path3:
>> >
On Sat, Sep 24, 2011 at 11:24 AM, Richard Guenther
wrote:
> On Thu, Sep 15, 2011 at 6:26 PM, Paolo Bonzini wrote:
>> On 09/15/2011 06:19 PM, Richard Henderson wrote:
>>>
>>> I wouldn't go that far. They *used* to be compiler barriers,
>>> but clearly som
On Mon, Sep 26, 2011 at 6:42 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/26/11 05:00, Richard Guenther wrote:
>> On Mon, Sep 26, 2011 at 9:39 AM, Jiangning Liu
>> wrote:
>>>>> * Without PRE,
>>>>>
>
On Tue, Sep 27, 2011 at 4:56 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 09/27/11 01:30, Richard Guenther wrote:
>
>>
>>> It knows something about prephitmp.6_1 and thus could simplify
>>> D.2734_9 = prephitmp_6.1
On Wed, Sep 28, 2011 at 12:18 PM, Kirill Yukhin wrote:
> Hi folks,
> I have a question. For DejaGNU we have only one option for each test.
>
> It may be e.g. either "dg-do" compile or "dg-do run". This is really
> not as suitable
>
> For instance, we cheking some new instructio autogeneration. We
On Tue, Oct 4, 2011 at 5:07 PM, Ulf Magnusson wrote:
> On Mon, Oct 3, 2011 at 10:22 PM, Ian Lance Taylor wrote:
>> Ulf Magnusson writes:
>>
>>> Is there some reason why GCC couldn't generate this code for the first
>>> version of C::f()? Is this a failure of optimization, or am I missing
>>> som
On Thu, Oct 13, 2011 at 6:57 PM, Andi Kleen wrote:
>> Or I am missing someting?
>
> I often see the x86 vectorizer with -mtune=generic generate a lot of
> complicated code just to adjust for potential misalignment.
>
> My thought was just if the alias oracle knows what the original
> declaration i
On Sat, Oct 15, 2011 at 11:52 PM, Ulrich Drepper wrote:
> I think gcc should allow the programmer to tell it something about a
> function return value even if the function is inlined and the compiler
> can see all the code. Consider the code below.
>
> If NOINLINE is defined the compiler will cal
On Mon, Oct 17, 2011 at 1:36 AM, Andi Kleen wrote:
> Ulrich Drepper writes:
>>
>> It's not guaranteed to work in general. The problem to solve is that
>> I know the function which is called is not clobbering any registers.
>> If I leave it with the normal function call gcc has to spill
>> regist
On Thu, Oct 20, 2011 at 10:36 AM, Basile Starynkevitch
wrote:
> On Thu, Oct 20, 2011 at 10:21:27AM +0200, Richard Guenther wrote:
>
>> I'd rather have a way to make dump-files more structured (so, following
>> some standard reporting scheme) than introducing yet another wa
On Thu, Oct 20, 2011 at 4:52 PM, Jonathan Wakely wrote:
> On 20 October 2011 12:56, Basile Starynkevitch wrote:
>>
>> (amongst those advocating C++ smart or whatever _ptr-s)
>
> Please stop saying "smart or whatever _ptr-s" - the term "smart
> pointer" has a commonly accepted meaning and is well u
On Fri, Oct 21, 2011 at 8:09 AM, Basile Starynkevitch
wrote:
> On Thu, 20 Oct 2011 17:13:46 +0200 (CEST)
> Marc Glisse wrote:
>
>> Can't you use GTY-ed memory in PPL? Sorry for the naive question, but
>> std::vector can take an allocator parameter, gmp lets you specify an
>> allocation function..
On Fri, Oct 21, 2011 at 4:53 PM, Aurelien Buhrig
wrote:
> Hi,
>
> I'm trying to port gcc 4.6.1 for a new target for which Pmode=PSI.
> I have an ICE in size_binop_loc, at fold-const.c:1433 when compiling
> gcc.c-torture/compile/92-1.c
>
> Here is the back trace
> #1 0x0060f8f3 in siz
On Fri, Oct 21, 2011 at 10:56 PM, Basile Starynkevitch
wrote:
> On Fri, 21 Oct 2011 10:43:29 +0200
> Richard Guenther wrote:
>> So there is no inherent limitation with the GGC machinery.
>
> There are at least some annoyances:
>
> If a C++ class is GTY-ed, or is pointed
On Mon, Oct 24, 2011 at 2:55 PM, Bingfeng Mei wrote:
> Hello,
> I noticed that COND_EXPR is not expanded to conditional move
> as MIN_EXPR/MAX_EXPR are (assuming movmodecc is available).
> I wonder why not?
>
> I have some loop that fails tree vectorization, but still contains
> COND_EXPR from tre
On Tue, Oct 25, 2011 at 1:25 AM, David Edelsohn wrote:
> On Sun, Oct 23, 2011 at 8:33 PM, Perry Smith wrote:
>
>> One more question on this quest (drifting a little more off topic).
>> In my log files I see a lot of these errors:
>>
>> ld: 0711-768 WARNING: Object
>> ../libsupc++/.libs/libsupc++c
On Wed, Oct 26, 2011 at 6:31 PM, Benjamin Kosnik wrote:
>
>> Whats left
>> ===
>> Functionality is pretty much complete, but there are a few minor lose
>> ends still to deal with. They could be done after a merge, in the
>> next stage, or required before... you tell me :-)
>>
>> - potentia
that
are not included in the list of primary and secondary targets.
Previous Report
===
http://gcc.gnu.org/ml/gcc/2011-10/msg00177.html
The next report will be sent by Jakub.
--
Richard Guenther
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF
On Fri, Oct 28, 2011 at 9:48 AM, David Miller wrote:
>
> g++.dg/init/copy7.C makes sure that memcpy() is not emitted with
> src and dst equal.
The testcase is bogus and should be removed. See the patch I posted
(and the PR). Unfortunately the patch didn't get any review yet.
> The fix installe
On Fri, Oct 28, 2011 at 12:21 PM, David Miller wrote:
> From: Richard Guenther
> Date: Fri, 28 Oct 2011 11:27:25 +0200
>
>> On Fri, Oct 28, 2011 at 9:48 AM, David Miller wrote:
>>>
>>> g++.dg/init/copy7.C makes sure that memcpy() is not emitted with
>>>
On Fri, Oct 28, 2011 at 12:54 PM, David Miller wrote:
> From: Richard Guenther
> Date: Fri, 28 Oct 2011 12:47:30 +0200
>
>> Then we have to fix the middle-end which will happily expand
>> block-moves to memcpy with exact overlap (a = a is valid in C).
>> See the PR
On Sun, Oct 30, 2011 at 5:38 AM, David Miller wrote:
>
> gcc.dg/pr48616.c segfaults on sparc as of a day or two ago
>
> vectorizable_shift() crashes because op1_vectype is NULL and
> we hit this code path:
>
> /* Vector shifted by vector. */
> if (!scalar_shift_arg)
> {
> optab = optab_
On Mon, Oct 31, 2011 at 11:33 PM, Aldy Hernandez wrote:
> This is somewhat of a me-too message for the transactional-memory work. We
> would also like it to be considered for merging with mainline before the end
> of stage1.
>
> We have a kept a wiki here:
>
> http://gcc.gnu.org/wiki/Transactiona
2011/11/1 杜越海 :
> Hi all
>
> I found IVopts rewrite a memory access with a weird iv candidate,
> which make it lost its original memory attribute.
> a non-local memory access' base pointer was rewrite into a local one,
> and it was deleted in pass_cd_dce since
> it was recognized as a local memo
On Tue, Nov 1, 2011 at 5:59 PM, David Edelsohn wrote:
> On Tue, Nov 1, 2011 at 5:49 AM, Richard Guenther
> wrote:
>
>> Given that you only recently merged with trunk again are you really
>> sure this is a great
>> idea at this point in time? Does the GCC 4.7 user comm
On Thu, Nov 3, 2011 at 3:20 PM, Dominique Dhumieres wrote:
> Revision 180821 breaks bootstrap on x86_64-apple-darwin10:
>
> ../../work/gcc/collect2.c: In function 'int main(int, char**)':
> ../../work/gcc/collect2.c:1094:7: error: unused variable 'object_nbr'
> [-Werror=unused-variable]
> cc1plus
On Thu, Nov 3, 2011 at 3:22 PM, Richard Guenther
wrote:
> On Thu, Nov 3, 2011 at 3:20 PM, Dominique Dhumieres
> wrote:
>> Revision 180821 breaks bootstrap on x86_64-apple-darwin10:
>>
>> ../../work/gcc/collect2.c: In function 'int main(int, char**)':
>>
On Thu, Nov 3, 2011 at 5:09 PM, Aldy Hernandez wrote:
>
>> Have you ever posted the patch, or only made it available via the website?
>
> Have you not seen the last 3 years of patches to gcc-patches? They're
> prefixed by [trans-mem]. Perhaps you're filtering them out.
>
>> Just scanning
>> http
On Thu, Nov 3, 2011 at 5:16 PM, Aldy Hernandez wrote:
>
>>> Reviewable patches as in what goes in gcc-patches? Or do you want
>>> something
>>> else?
>>
>> Reviewable branch merge patch(es). You can't expect everyone to
>> follow all development branches that may or may not end up being merged.
On Mon, Nov 7, 2011 at 9:58 PM, Aldy Hernandez wrote:
> Dear Release Managers...
>
> We're pretty much done with the merge blockers, and even suggestions that
> weren't blockers :). The only outstanding patch review is a cleanup by
> Richard Henderson that is waiting for Richi's review here:
>
>
On Thu, Nov 10, 2011 at 2:35 PM, Arnaud Charlet wrote:
>> The entries in parens are only covered indirectly and may or may not
>> warrant their own components. I'd argue that it would be helpful to
>> have libada and libgo components of their own (while libcpp would
>> probably be overkill), but
On Mon, Nov 14, 2011 at 4:58 AM, Yuehai Du wrote:
> Hi
>
> i found IVOPTS didn't work well on some case if the loop contain
> some unaligned access. it didn't take this kind of memory access into
> account because this check in function:find_interesting_uses_address
>
> /* Moreover, on stric
On Mon, Nov 14, 2011 at 9:01 AM, Jiangning Liu wrote:
> Hi,
>
> For this test case,
>
> int x;
> extern void f(void);
>
> void g(int *a)
> {
> a[x] = 1;
> if (x == 100)
> f();
> a[x] = 2;
> }
>
> For trunk, the x86 assembly code is like below,
>
> movl
On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou wrote:
>> Huh, IVOPTs should never cause a different size memory read. I wonder
>> if the original issue would still reproduce with the fix reverted.
>
> The original issue was unaligned arrays in packed structures. I don't see
> what
> could have
On Thu, Nov 17, 2011 at 7:27 PM, Diego Novillo wrote:
>
> Gerald, I've been searching for the release criteria pages for various
> releases. I haven't found anything. I was expecting to find them as
> top-level links on the home page.
>
> Should I prepare a patch? Or should I have looked in a d
On Thu, Nov 17, 2011 at 8:19 PM, Richard Guenther
wrote:
> On Thu, Nov 17, 2011 at 7:27 PM, Diego Novillo wrote:
>>
>> Gerald, I've been searching for the release criteria pages for various
>> releases. I haven't found anything. I was expecting to find them as
On Fri, Nov 18, 2011 at 2:07 AM, Yuehai Du wrote:
> 2011/11/18 Richard Guenther :
>> On Thu, Nov 17, 2011 at 6:49 AM, Yuehai Du wrote:
>>> 2011/11/17 Richard Guenther :
>>>> On Wed, Nov 16, 2011 at 12:28 PM, Eric Botcazou
>>>> wrote:
>>>
On Thu, Dec 1, 2011 at 11:12 AM, Amker.Cheng wrote:
> On Sat, Nov 26, 2011 at 3:41 PM, Amker.Cheng wrote:
>> Hi,
>> I looked into PR43491 a while and found in this case the gimple
>> generated before pre
>> is like:
>>
>> reg.0_12 = reg
>> ...
>> c()
>> reg.0_1 = reg
>> D.xxx = MEM[reg.0_1 + 8B]
On Thu, Dec 1, 2011 at 10:40 PM, Georg-Johann Lay wrote:
> Ian Lance Taylor wrote:
>
>> Georg-Johann Lay writes:
>>
>>> If general_operand can be perceived as
>>>
>>> (define_predicate "general_operand"
>>> (ior (match_operand 0 "memory_operand")
>>> (match_operand 0 "register_operand")
>>>
On Fri, Dec 2, 2011 at 1:14 PM, Peter Bigot wrote:
> On Fri, Dec 2, 2011 at 5:46 AM, wrote:
>>
>> ...
>> >> It's never correct to exchange volatile accesses.
>> >
>> >That's not true. volatile accesses to different memory locations
>> >have no special dependence. If it happens that GCC doesn't
for sub-optimal
>>> > >code with volatile - we don't even try to do legal transformations).
>> >
>> > I'm confused. Do you mean that in
>> > Volatile int *a, *b;
>> > Int j, k;
>> > J = *a; k = *b;
>> > it is ok
On Sat, Dec 3, 2011 at 12:42 AM, Richard Henderson wrote:
> On 12/02/2011 06:35 AM, Richard Guenther wrote:
>> I see. As we do not explicitely model this dependency we probably
>> get lucky by the if (gimple_has_volatile_ops ()) bail-out; most
>> passes do.
>
> What
On Sat, Dec 3, 2011 at 7:56 PM, Richard Henderson wrote:
> On 12/03/2011 06:30 AM, Richard Guenther wrote:
>> Not if you look at the respective gimple level dependency routines
>> in tree-ssa-alias.c, OTOH tree-data-ref.c simply refuses to handle
>> volatile referenc
On Sun, Dec 4, 2011 at 6:16 PM, Gerald Pfeifer wrote:
> On Thu, 17 Nov 2011, Richard Guenther wrote:
>> I indeed do not see where we link to criteria.html. I think we should
>> duplicate the list of primary/secondary targets on the releases
>> index.html page(?) and
On Sun, 4 Dec 2011, Richard Guenther wrote:
> On Sat, Dec 3, 2011 at 7:56 PM, Richard Henderson wrote:
> > On 12/03/2011 06:30 AM, Richard Guenther wrote:
> >> Not if you look at the respective gimple level dependency routines
> >> in tree-ssa-alias.c, OTOH tree-d
On Tue, Dec 6, 2011 at 11:00 AM, Amker.Cheng wrote:
> On Thu, Dec 1, 2011 at 11:45 PM, Richard Guenther
> wrote:
>
>> Well, it's not that easy if you still want to properly do redundant
>> expression
>> removal on global registers.
>
> Yes, it might be
On Tue, Dec 6, 2011 at 2:13 PM, Dave Korn wrote:
> On 05/12/2011 21:43, Jeff Law wrote:
>
>> When the uninitialized & initialized to 10 paths meet, the compiler
>> (correctly) pretends the value for the uninitialized path is 10 as
>> well.
>
> Wouldn't that be a good point at which to issue an un
On Thu, Dec 8, 2011 at 12:34 PM, Bingfeng Mei wrote:
> Hi,
> I experienced a code generation bug with 4.5 (yes, our
> port is still stuck at 4.5.4). Since the concerned code
> is full of our target-specific code, it is not easy
> to demonstrate the error with x86 or ARM.
>
> Here is what happens i
On Thu, Dec 8, 2011 at 1:26 PM, Martin Jambor wrote:
> Hi,
>
> On Thu, Dec 08, 2011 at 10:38:24AM +0100, Feng LI wrote:
>> Hi,
>>
>> I'm building a function with
>> fread = build_decl (LOCATION, FUNCTION_DECL, get_identifier (name), type);
>>
>> and then use it in gimple with
>> gimple gfread = gi
On Thu, Dec 8, 2011 at 2:49 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 8 Dec 2011, Richard Guenther wrote:
>
>> > What I am not sure is whether the coalescing algorithm or the
>> > expanding procedure is wrong here.
>
> The forwarding of _218 is wrong. TER shou
On Mon, Dec 12, 2011 at 12:13 AM, Georg-Johann Lay wrote:
> Bringing this over from gcc-patches@
>
> Jakub Jelinek wrote:
>>
>> On Fri, Dec 09, 2011 at 01:50:37PM +0100, Georg-Johann Lay wrote:
>>
>>> No, not OK.
>>>
>>> This leads to unacceptable code for devices that cannot shift easily
>>> like
On Mon, Dec 12, 2011 at 2:48 PM, BELBACHIR Selim
wrote:
> Everything seems good when I use a union instead of "*((int *)(&af))".
>
> But I think that "*((int *)(&af))" is a valid syntax to get the integer
> representation of my floating point value (in my test case 0x3F80 for
> 1.0f in IEEE-
On Tue, 13 Dec 2011, Kirill Yukhin wrote:
> Hi guys,
> While looking at Spec2006/401.bzip2 I found such a loop:
> for (i = 1; i <= alphaSize; i++) {
> j = weight[i] >> 8;
> j = 1 + (j / 2);
> weight[i] = j << 8;
> }
>
> Which is not vectorizeble (using Intel's AVX2) beca
On Thu, Dec 15, 2011 at 2:41 PM, Amker.Cheng wrote:
> HI,
> I encountered a case with below codes:
>
> int data_0;
> int motion_test1(int data, int v)
> {
> int i;
> int t, u;
> int x;
>
> if (data)
> i = data_0 + x;
> else {
> v = 2;
>
On Tue, Dec 20, 2011 at 2:23 PM, Rohit Arul Raj wrote:
> Hello All,
>
> With the code given below, i expected the ppc compiler (e500mc v4.6.2)
> to generate 'memset' zero call for loop initialization (at '-O3'),
> but it generates a loop.
>
> Case:1
>
> int a[18], b[18];
> foo () {
> int i;
>
>
On Thu, Dec 22, 2011 at 9:25 AM, Jiangning Liu wrote:
>> Yes, the number of iterations of the i loop simply is too difficult fo
>> our loop iteration calculator to comprehend:
>>
>> for (i=k; i<500; i+=k)
>>
>> iterates for roundup((500-k)/k) time. In particular if the step is
>> non-constant o
On Thu, Dec 29, 2011 at 5:24 PM, Richard Sandiford
wrote:
> AIUI, the outcome of PR38964 was that we can't use TBAA for testing an
> anti_dependence between a load X and store Y because Y might be defining
> a new object in the same space as the object that was being read by X.
> But it looks like
501 - 600 of 2444 matches
Mail list logo
