Hello!
> While I'm here, in i386.md some of the flag setting operations specify a mode
> and some don't . Eg
>
> (define_expand "cmp_1"
> [(set (reg:CC FLAGS_REG)
> (compare:CC (match_operand:SWI48 0 "nonimmediate_operand")
>
>
> (define_insn "*add_3"
> [(set (reg FLAGS_REG)
> (compar
On Fri, 29 Aug 2014, ConcertPass Mirrors Admin wrote:
> we set up a new GCC mirror for the community.
>
> URL: http://mirrors.concertpass.com/gcc/
> Organization/Contact: ConcertPass (ad...@mirrors.concertpass.com)
> Location: United States, Michigan
>
> Please, add it to your mirror list page.
Snapshot gcc-4.9-20140903 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20140903/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
For a 16 bit CPU the cmpelim pass is changing
(insn 33 84 85 6 (parallel [
(set (reg:HI 1 r1)
(ashift:HI (reg:HI 1 r1)
(const_int 1 [0x1])))
(clobber (reg:CC_NOOV 7 flags))
]) ../gcc/testsuite/gcc.c-torture/execute/960311-3.c:18
Joel Sherrill writes:
> On 9/3/2014 1:24 PM, Jeff Law wrote:
>> On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
>>> Perhaps m5206 is not TARGET_CAS and should not compile this linux-atomic
>>> in the first place?
>> No, I don't think so.
> Coldfire does not have the CAS instruction per
> http:
On 2014-08-29 2:47 AM, Ilya Enkovich wrote:
Seems your patch doesn't cover all cases. Attached is a modified
patch (with your changes included) and a test where double constant is
wrongly rematerialized. I also see in ira dump that there is still a
copy of PIC reg created:
Initialization of or
On Wed, 3 Sep 2014, Joern Rennecke wrote:
> On 2 September 2014 16:28, Joseph S. Myers wrote:
> > On Tue, 2 Sep 2014, Joey Ye wrote:
> >
> >> Apparently newlib is not following this specification very well, as
> >> there are symbols like _abc_r defined every where in current newlib. I
> >> am not
On 2 September 2014 16:28, Joseph S. Myers wrote:
> On Tue, 2 Sep 2014, Joey Ye wrote:
>
>> Apparently newlib is not following this specification very well, as
>> there are symbols like _abc_r defined every where in current newlib. I
>> am not implying the spec should not be followed, but is newli
On 9/3/2014 1:24 PM, Jeff Law wrote:
> On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
>> Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
>> that wants to assure that the stack is aligned properly.
>>
>> PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
>> t
On 09/03/14 09:56, Bernhard Reutner-Fischer wrote:
Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
that wants to assure that the stack is aligned properly.
PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
the testcase below has stack_pointer_delta = 1 + 1 +
On Tue, Sep 2, 2014 at 7:32 AM, Maxim Ostapenko
wrote:
> Hi,
>
> At this moment, most of GCC builtin memory functions (for example strcpy,
> stpcpy, wcpcpy, strdup, etc) are not instrumented by GCC, however some of
> them are rather dangerous. If GCC inlines these builtin functions, we will
> miss
On Wed, Sep 3, 2014 at 1:29 AM, Steven Bosscher wrote:
> On Wed, Sep 3, 2014 at 1:35 AM, Carrot Wei wrote:
>> 1. It is well known that register renaming is a big help to register
>> allocation, but in gcc's backend, the web pass is far before RA, there
>> are about 20 passes between them. Does it
On Wed, 3 Sep 2014, Florian Weimer wrote:
> > If you declare the size as [static sz] then
> > that means it points to an array of at least that size, but it could be
> > larger.
>
> GCC does not seem to enforce that. This compiles without errors:
[static] is about optimization (but GCC doesn't
On 09/03/2014 05:20 PM, Joseph S. Myers wrote:
On Wed, 3 Sep 2014, Florian Weimer wrote:
On 09/02/2014 11:22 PM, James Nelson wrote:
This is error-prone because even though a size parameter is given, the code
in the function has no requirement to enforce it. With a bounded array
type, the pro
Trying to bootstrap m68k i hit an assert in emit_library_call_value_1
that wants to assure that the stack is aligned properly.
PUSH_ROUNDING(GET_MODE_SIZE(QImode)) for m5206 is currently 1 so
the testcase below has stack_pointer_delta = 1 + 1 + 4
but emit_library_call_value_1() has this:
/* Sta
Hi Shanyao,
On 03/09/14 16:02, shanyao chen wrote:
Hi,
I found there is a performance problem with some simd intrinsics
(vld2_dup_*) on aarch64-none-elf. Now the vld2_dup_* are defined as
follows:
#define __LD2R_FUNC(rettype, structtype, ptrtype, \
regsuffix, funcsuffix, Q) \
__extensio
On 09/03/14 02:35, Steven Bosscher wrote:
On Wed, Sep 3, 2014 at 9:17 AM, Bin.Cheng wrote:
Last time I tried, there are several passes after loop_done and before
auto-inc-dec can't handle auto-increment addressing mode, including
fweb.
It surprises me that pass_web can't handle AUTOINC. Perhap
On Wed, 3 Sep 2014, Florian Weimer wrote:
> On 09/02/2014 11:22 PM, James Nelson wrote:
>
> > This is error-prone because even though a size parameter is given, the code
> > in the function has no requirement to enforce it. With a bounded array
> > type, the prototype looks like this:
> >
> > bu
Hi,
I found there is a performance problem with some simd intrinsics
(vld2_dup_*) on aarch64-none-elf. Now the vld2_dup_* are defined as
follows:
#define __LD2R_FUNC(rettype, structtype, ptrtype, \
regsuffix, funcsuffix, Q) \
__extension__ static __inline rettype \
__attribute__ ((__always
On Wed, Sep 03, 2014 at 10:35:41AM +, VandeVondele Joost wrote:
> >> expect -- /usr/share/dejagnu/runtest.exp --tool gcc lto.exp weak.exp
> >> tls.exp ipa.exp tree-ssa.exp debug.exp >dwarf2.exp fixed-point.exp
> >> vxworks.exp cilk-plus.exp vmx.exp pch.exp simulate-thread.exp
> >> x86_64-co
>> expect -- /usr/share/dejagnu/runtest.exp --tool gcc lto.exp weak.exp tls.exp
>> ipa.exp tree-ssa.exp debug.exp >dwarf2.exp fixed-point.exp vxworks.exp
>> cilk-plus.exp vmx.exp pch.exp simulate-thread.exp x86_64-costmodel-vect.exp
>> i386-costmodel-vect.exp spu-costmodel-vect.exp ppc-costmodel
> I have to admit that I don't know why that's the case.
Actually Marc answered that one (I had the wrong mail address for gcc@ so
repeat here):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53155
> See: gcc/fortran/Make-lang.in, which has:
I'll have a look and do some testing what the gains/co
Hi Joost,
VandeVondele Joost wrote:
> I've noticed that
> make -j -k check-fortran
> results in a serialized checking, while
> make -j32 -k check-fortran
> goes parallel.
I have to admit that I don't know why that's the case. However, I can answer
the next question, is presumably related to thi
On Wed, Sep 03, 2014 at 09:37:19AM +, VandeVondele Joost wrote:
> > It is intentional. With -j it is essentially a fork bomb, just don't use
> > it.
>
> well, silently ignoring it for just this target did cost me a lot of time,
> while an eventual fork bomb would have been dealt with much
> What did you expect for -j alone? an error?
No, as is standard in gnu make, a new process for any target that can be
processed (i.e. unlimited).
>> ... check-fortran seems to be limited to about ~5 parallel targets ...
>
>Running the make with -j8 gives 7 directories gfortran[1-6]? in gcc/tes
> It is intentional. With -j it is essentially a fork bomb, just don't use it.
well, silently ignoring it for just this target did cost me a lot of time,
while an eventual fork bomb would have been dealt with much more quickly.
>> Somewhat related is there a rule of thumb on how is the gran
On Wed, Sep 03, 2014 at 09:15:51AM +, VandeVondele Joost wrote:
> I've noticed that
>
> make -j -k check-fortran
>
> results in a serialized checking, while
>
> make -j32 -k check-fortran
>
> goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the
> check target, while th
On Wed, 3 Sep 2014, VandeVondele Joost wrote:
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the check
target, while the other targets seem to do just fine.
I've noticed that
make -j -k check-fortran
results in a serialized checking, while
make -j32 -k check-fortran
goes parallel. Somehow the explicit 'N' in -jN seems to be needed for the check
target, while the other targets seem to do just fine. Is that a feature, or
should I file a PR for that
On Wed, Sep 3, 2014 at 9:17 AM, Bin.Cheng wrote:
> Last time I tried, there are several passes after loop_done and before
> auto-inc-dec can't handle auto-increment addressing mode, including
> fweb.
It surprises me that pass_web can't handle AUTOINC. Perhaps I'm off my
rocker, but it's always bee
On Wed, Sep 3, 2014 at 1:35 AM, Carrot Wei wrote:
> 1. It is well known that register renaming is a big help to register
> allocation, but in gcc's backend, the web pass is far before RA, there
> are about 20 passes between them. Does it mean register renaming can
> also heavily benefit other optim
On 09/02/2014 11:22 PM, James Nelson wrote:
This is error-prone because even though a size parameter is given, the code
in the function has no requirement to enforce it. With a bounded array
type, the prototype looks like this:
buf *foo(char buf[sz], size_t sz);
GCC already has a syntax exten
On Mon, Sep 1, 2014 at 9:14 AM, Peng Fan wrote:
>
>
> On 09/01/2014 08:09 AM, Matt Thomas wrote:
>>
>> On Aug 31, 2014, at 11:32 AM, Joel Sherrill
>> wrote:
>>
Hi,
I am writing some code and found that system crashed. I found it was
unaligned access which causes `data abort`
On Wed, Sep 3, 2014 at 7:35 AM, Carrot Wei wrote:
> Hi
>
> I have following questions about web (pseudo register renaming) pass:
>
> 1. It is well known that register renaming is a big help to register
> allocation, but in gcc's backend, the web pass is far before RA, there
> are about 20 passes b
34 matches
Mail list logo
