> The "mov.L r6, r0" instruction must never be marked as frame-related, for any
> function.
Also, is that rule true if we *don't* have a frame pointer? That is,
when we add a constant to the stack to allocate the frame, should that
function be marked as frame-related? Or is it just the fp->sp
> The "mov.L r6, r0" instruction must never be marked as frame-related, for any
> function.
Is this documented somewhere?
> 0010 CIE
> Version: 3
> Augmentation: ""
> Code alignment factor: 1
> Data alignment factor: -4
> Return address column: 17
>
> DW_CFA_def_cfa: r0 ofs 4
> DW_CFA_offset: r17 at cfa-4
> DW_CFA_nop
> DW_CFA_nop
OK so r0 (sp) is the CF
> I gather that r0 is the stack pointer and r6 the frame pointer?
Yes.
> > 0014 0030 FDE cie= pc=..0043
> > DW_CFA_advance_loc4: 2 to 0002
> > DW_CFA_def_cfa_offset: 32
> > DW_CFA_offset: r12 at cfa-8
> > . . .
> > DW_CFA_offset: r6 at cfa-32
>
> The last stack adjustment it sees is
> the rx backend's adjustment to allocate the frame:
>
> _medium_frame:
> pushm r6-r12
> add #-4, r0, r6 ; marked frame-related (fp = sp -
> 4) mov.L r6, r0 ; marked frame-related (sp = fp) . .
> .
Snapshot gcc-4.8-20140417 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140417/
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
On Thu, Apr 17, 2014 at 10:14 AM, DJ Delorie wrote:
>
> The rx back-end doesn't define TARGET_FRAME_POINTER_REQUIRED, as the
> documentation says the compiler handles target-independent reasons why
> there needs to be a frame pointer. But, the default
> TARGET_FRAME_POINTER_REQUIRED just returns
> Presumably the rx back-end and more precisely TARGET_FRAME_POINTER_REQUIRED,
> which needs to return true if cfun->calls_alloca.
The rx back-end doesn't define TARGET_FRAME_POINTER_REQUIRED, as the
documentation says the compiler handles target-independent reasons why
there needs to be a frame
On Sat, Apr 12, 2014 at 12:53:45AM +0200, Hannes Frederic Sowa wrote:
> Hi!
>
> On Tue, Oct 29, 2013 at 10:41:56AM +0100, Richard Biener wrote:
> > For a "quick" GCC implementation of the builtins you could expand
> > them to a open-coded sequence during gimplification. But due to
> > the issues
Hi,
On Thu, 17 Apr 2014, Richard Sandiford wrote:
> > "The constraints on a ‘movm’ must permit moving any hard register to
> > any other hard register provided..."
> >
> > by providing a define_expand that assigns from a general_operand to a
> > nonimmediate_operand and ...
> >
> > *ldsi instru
On Thu, Apr 17, 2014 at 02:04:03PM +0200, Jakub Jelinek wrote:
> Ugh, I guess depends on how the patch looks like.
> In any case, I think libgomp contains pretty much the same hunk as cilkrts,
> so why you don't run into issues in libgomp and only in libcilkrts?
>
> # Check to see if -pthread or -
On Thu, Apr 17, 2014 at 03:40:10PM +0400, Alexander Ivchenko wrote:
> That fixes "--disable-shared" case only, which is important for NDK build.
>
> Without "--disable-shared" build fails because there is no -lpthread
> on Android and pthreads are in libc there.
> Apparently, cilkrts configure doe
That fixes "--disable-shared" case only, which is important for NDK build.
Without "--disable-shared" build fails because there is no -lpthread
on Android and pthreads are in libc there.
Apparently, cilkrts configure does not check that.
I can fix that in 4.9, but I'm ok with fixing it in trunk l
On Thu, Apr 17, 2014 at 02:47:50PM +0400, Alexander Ivchenko wrote:
> Is it ok to port this patch to 4.9 branch:
If it always fails to bootstrap with cilkrts on Android right now, then
the patch can't do more harm, so ok.
>
> commit 15bee5d49b1c746fd3e784432d7e4988941a671e
> Author: bviyer
> Dat
pshor...@dataworx.com.au writes:
> On 17.04.2014 13:00, Jeff Law wrote:
>> On 04/16/14 16:19, Richard Henderson wrote:
>>>
>>> The register allocators only select an alternative for a move. They
>>> do not
>>> choose between N different patterns, separately describing loads,
>>> stores, and
>>>
On Thu, Apr 17, 2014 at 12:39 PM, Konstantin Vladimirov
wrote:
> Hi,
>
> I want to support, say arch1 and arch2 in custom gcc in the way
>
> gcc -march1 test.c
>
> calls
>
> ${INSTALL}/libexec/gcc/arch1/4.8.2/cc1
>
> and
>
> gcc -march2 test.c
>
> calls
>
> ${INSTALL}/libexec/gcc/arch2/4.8.2/cc1
>
Is it ok to port this patch to 4.9 branch:
commit 15bee5d49b1c746fd3e784432d7e4988941a671e
Author: bviyer
Date: Fri Apr 11 19:56:42 2014 +
Fix for PR other/60644.
+2014-04-11 Barry Tannenbaum
+
+ PR other/60644
+ * runtime/os-unix.c: Replaced all occurran
Hi,
I want to support, say arch1 and arch2 in custom gcc in the way
gcc -march1 test.c
calls
${INSTALL}/libexec/gcc/arch1/4.8.2/cc1
and
gcc -march2 test.c
calls
${INSTALL}/libexec/gcc/arch2/4.8.2/cc1
Are there any way to do it? Maybe not exactly as I outlined, but the
whole idea is clear,
W dniu 2014-04-17 12:13, Jonathan Wakely napisał(a):
On 17 April 2014 10:38, Paweł Sikora wrote:
Hi,
the opt_random.h header includes unconditionally and
breaks
crytopp build
(redefinition of _mm_shuffle_epi8 in cpu.h).
could you please add #ifdef __SSSE3__ around this include?
Do you mean
On 17 April 2014 10:38, Paweł Sikora wrote:
> Hi,
>
> the opt_random.h header includes unconditionally and breaks
> crytopp build
> (redefinition of _mm_shuffle_epi8 in cpu.h).
> could you please add #ifdef __SSSE3__ around this include?
Do you mean __SSE3__ not __SSSE3__?
That's the macro that c
On Thu, Apr 17, 2014 at 11:38:18AM +0200, Paweł Sikora wrote:
> Hi,
>
> the opt_random.h header includes unconditionally and
> breaks crytopp build
> (redefinition of _mm_shuffle_epi8 in cpu.h).
> could you please add #ifdef __SSSE3__ around this include?
No, just fix cryptopp.
The *intrin.h hea
Hi,
the opt_random.h header includes unconditionally and
breaks crytopp build
(redefinition of _mm_shuffle_epi8 in cpu.h).
could you please add #ifdef __SSSE3__ around this include?
BR,
Paweł.
cpu.h @ cryptopp:
(...)
#if !defined(__GNUC__) || defined(__SSSE3__) ||
defined(__INTEL_COMPILER)
> While debugging some gdb-related FAILs, I discovered that gcc's
> -fstack-check option effectively calls alloca() to adjust the stack
> pointer.
Note that the subject is misleading, -fstack-check is stack checking and not
stack protection, which is -fstack-protector.
> However, it doesn't mark
23 matches
Mail list logo
