On 09/13/2013 01:02 PM, Chung-Ju Wu wrote:
> 2013/9/13 Chen Gang :
>> > On 09/13/2013 01:09 AM, Jeff Law wrote:
>>> >> On 09/11/2013 10:38 PM, Chen Gang wrote:
>>> Hello all:
>>>
> [...]
>>> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other
>>> bugs may dupl
2013/9/13 Chen Gang :
> On 09/13/2013 01:09 AM, Jeff Law wrote:
>> On 09/11/2013 10:38 PM, Chen Gang wrote:
>>> Hello all:
>>>
[...]
>>> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other
>>> bugs may duplicate with these bugs, so I do not send (if they are also
>>> valuable, I
On 09/13/2013 01:09 AM, Jeff Law wrote:
> On 09/11/2013 10:38 PM, Chen Gang wrote:
>> Hello all:
>>
>> I have send the related issues to "http://gcc.gnu.org/bugzilla";, please
>> check if you like, thanks.
>>
>> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other
>> bugs may dupl
Snapshot gcc-4.8-20130912 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20130912/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> may_trap_or_fault_p() does the right thing by taking the misalignement
> of stack accesses into account on STRICT_ALIGN targets. Would it be a
> solution to call that instead may_trap_p() from
> haifa-sched.c:may_trap_exp() ?
That wouldn't be the first time that this replacement is done.
> I'm
On Thu, 2013-09-12 at 17:39 +0200, Frederic Riss wrote:
> The issue is that I am using super-block
> scheduling in sched2 and that my sched_reorder hook prioritized the
> load operation over the conditional branch that did the alignment
> check.
>
> I'm now leaning toward a scheduler bug (or my cu
Hello,
we created mirrors for GCC. Please add them to your public mirror list:
+ Mirrors-usa:
http://mirrors-usa.go-parts.com/gcc/
ftp://mirrors-usa.go-parts.com/gcc/
rsync://mirrors-usa.go-parts.com/mirrors/gcc/
+ Mirrors-russia:
http://mirrors-ru.go-parts.com/gcc/
ftp:
On behalf of myself and Nick, many thanks to everyone involved in
reviewing this port! I've checked in the port as per the last
(approved) patch set I sent out.
On 09/11/2013 10:38 PM, Chen Gang wrote:
> Hello all:
>
> I have send the related issues to "http://gcc.gnu.org/bugzilla";, please
> check if you like, thanks.
>
> currently, I only send 3 bugs: Bug58256, Bug58400, Bug58401, the other
> bugs may duplicate with these bugs, so I do not send (if the
On 12 September 2013 12:47, Richard Biener wrote:
> Look at the -fdump-tree-vect-details, it should print what it does during
> alignment analysis. Then debug the code ...
OK, I think I got to the bottom of this. It's not the vectorizer fault
after all. Jakub was right to point out that there is
On Thu, Sep 12, 2013 at 11:59 AM, Frederic Riss wrote:
> On 12 September 2013 11:25, Richard Biener wrote:
>> You may simply hit some bug in the vectorizer. The vectorizer assumes
>> it can re-align local decls, and for the above it should use
>> known-misalignment
>> accesses. You can check w
Hello all,
I have a doubt related to libitm.a and its objects. I hope this is the
right place to ask and get something clear.
We are crosscompiling gcc (4.7.3) for ARM using own crosstools built
from scratch.
This is the output from our current gcc built in our toolchain used to
rebuild gcc a
On 12 September 2013 11:25, Richard Biener wrote:
> You may simply hit some bug in the vectorizer. The vectorizer assumes
> it can re-align local decls, and for the above it should use
> known-misalignment
> accesses. You can check with -fdump-rtl-expand-details-alias what the
> MEMs think they
On Thu, Sep 12, 2013 at 11:25:31AM +0200, Richard Biener wrote:
> On Thu, Sep 12, 2013 at 10:40 AM, Frederic Riss
> wrote:
> > Thus I'm wondering if the vectorizer makes the assumption that a
> > target must be able to load/store vectors aligned on any element size
> > boundary. If it's the case,
On Thu, Sep 12, 2013 at 10:40 AM, Frederic Riss wrote:
> Hello,
>
> I have coded SIMD support for my target, but I'm hitting some issues
> relative to alignment. I can't find any documentation or comment
> describing the assumptions that the vectorizer makes about target
> support, if it exists pl
Hello,
I have coded SIMD support for my target, but I'm hitting some issues
relative to alignment. I can't find any documentation or comment
describing the assumptions that the vectorizer makes about target
support, if it exists please just point me at it (I'm based on GCC 4.7
for now).
On my tar
16 matches
Mail list logo
