Hi,
> I was wondering if it was possible to turn off the unrolling to
> certain loops. Basically, I'd like the compiler not to consider
> certain loops for unrolling but fail to see how exactly I can achieve
> that.
>
> I've traced the unrolling code to multiple places in the code (I'm
> working
On 10/05/2009 07:02 AM, Mohamed Shafi wrote:
. But now it seems that i
need to split the pattern before reload also.
Oh? Why?
The only addressing mode
supported for accessing this section is (SP+offset).
Ouch. Is there no general register to high-8bit move either?
So you can't do
load
That's super! Thank you Antoniu. With the capacity of printing the
expanded code, it feels a lot more freedom now when reading the source
code of libgomp.
Cheers,
Tim
On Mon, Oct 5, 2009 at 8:29 AM, Antoniu Pop
wrote:
> Hi Tim,
>
>
>> From gcc online docs (http://gcc.gnu.org/onlinedocs/libgomp/)
Richard,
> If you are not working on trunk this can happen because the way
> MEM_EXPRs are "canonicalized".
Thanks. Yes, I am not on trunk and may not be able to move right away.
I would appreciate some pointers about where I should look, If I want
to fix this ?
Thanks,
Pranav
Installed /usr/ports/devel/libelf [0.8.12] on i386-*-freebsd7.2.
Explicitly added "--enable-lto --with-libelf=/usr/local" to configure line.
(Stock system's /usr/include/libelf.h missing elf_getshdrstrndx().)
New failures for i386-*-freebsd7.2 (seems in-line with other port reports):
gcc:
FAIL: g
On 10/05/2009 11:09 AM, Larry Evans wrote:
The work in 4.5 on O(1) template instantiation lookup time is already
showing benefits:
Glad to hear it!
Jason
Dear all,
I was wondering if it was possible to turn off the unrolling to
certain loops. Basically, I'd like the compiler not to consider
certain loops for unrolling but fail to see how exactly I can achieve
that.
I've traced the unrolling code to multiple places in the code (I'm
working with the
Hello all.
I try to compile the following code sample:
(with MinGW gcc version 4.5.0 20090819 (experimental) (GCC))
#include
#include
#include
template
struct Message
{
std::array m_Message;
Message() : m_Message{Chars...} // {*1}
{
std::array msg
"Jon Beniston" writes:
> Hi Richard,
>
>>> Index: gcc/config/lm32/sfp-machine.h
>>> Index: gcc/config/lm32/crti.S
>>> Index: gcc/config/lm32/lib1funcs.S
>>> Index: gcc/config/lm32/crtn.S
>>> Index: gcc/config/lm32/arithmetic.c
>>> Index: gcc/config/lm32/t-fprules-softfp
>>> Index: gcc/config/lm32
Denis Onischenko writes:
> I am getting the following error when compiling "x86_64 to powerpc64"
> cross gcc, as soon as the libgcc_s.so.1 has appeared in obj/gcc
> directory.
This question would be more appropriate for the mailing list
gcc-h...@gcc.gnu.org. Please take any followups there. Th
Zoltán Kócsi writes:
> Is there a documentation of the various magic letters that you can
> apply to an operand in inline assembly?
Unfortunately, no.
> The
> only place I found some information was going through the
> gcc/config//.c file and trying to find the meaning of such
> letters in the
The work in 4.5 on O(1) template instantiation lookup time is already
showing benefits:
http://article.gmane.org/gmane.comp.lib.boost.devel/194545
http://article.gmane.org/gmane.comp.lib.boost.devel/194538
http://www.boostpro.com/vault/index.php?&directory=variadic_templates
in tuple.benchmark.
Diego Novillo writes:
> The LTO branch has been merged into trunk at revision 152434.
> [...]
Congrats.
> [...] That's it. The result should, in principle, execute faster
> but our IPA cost models are still not tweaked for LTO. We've seen
> speedups as well as slowdowns in benchmarks (see th
2009/9/14 Richard Henderson :
> On 09/14/2009 07:24 AM, Mohamed Shafi wrote:
>>
>> Hello all,
>>
>> I am doing a port for a 32bit target in GCC 4.4.0. I have to support a
>> 40bit data (_Accum) in the port. The target has 40bit registers which
>> is a GPR and works as 32bit reg in other modes. The
Hi,
On Tue, 6 Oct 2009, Paul Edwards wrote:
> Thanks Michael. That's exactly the sort of thing I was after. Just
> one thing - I'll need more than cc1. I need the files that normally
> go into gcc as well. So a combination of those two sets of source,
> so that I can get a single standalone e
.../configure --target=i370-mvs --prefix=... --with-sysroot=... \
--enable-languages=c
Thanks Ulrich. That's very different from the concept I had of
how the build process was meant to work.
Ignoring the cross stuff, if this is all you need I would suggest calling
make in the r
Hi,
On Sun, 4 Oct 2009, Paul Edwards wrote:
> With 3.4.6, I have a script called "compile", which looks like this:
>
> call stdcomp alias.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp alloc-pool.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp attribs.c %1 %2 %3 %4 %5 %6 %7 %8 %9
> call stdcomp bb-reor
Paul Edwards wrote:
> Would you be able to give me the two suggested configure
> commands so that I can find out the answer to the above, one
> way or another?
For step 2 (building the cross-compiler), you'd need something
along the lines of
.../configure --target=i370-mvs --prefix=... --with-s
Trunk is once again open for commits under stage 3 rules.
Diego.
19 matches
Mail list logo
