> So in effect, we have two pointer sizes, 64 being the default, but
> we can also get a 32 bit pointer via the syntax above? Wow, I'm
> surprised that works.
Yup, been that way for many years.
> And the only time we'd be able to use larl is a dereference of a
> pointer declared with the syntax
On 07/08/2015 03:05 PM, DJ Delorie wrote:
In the TPF case, the software has to explicitly mark such pointers as
SImode (such things happen only when structures that contain addresses
can't change size, for backwards compatibility reasons[1]):
int * __attribute__((mode(SImode))) ptr;
ptr = &s
Snapshot gcc-4.9-20150708 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150708/
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
On Wed, Jul 08, 2015 at 03:15:12PM -0600, Jeff Law wrote:
> >For other archs, e.g. x86-64, you can do
> >
> > register void *sp asm("%sp");
> > asm volatile("call func" : "+r"(sp));
> >
> >I've found that putting "sp" in the clobber list also seems to work:
> >
> > asm volatile("c
On Wed, Jul 08, 2015 at 04:14:20PM -0500, Segher Boessenkool wrote:
> On Wed, Jul 08, 2015 at 03:51:12PM -0500, Josh Poimboeuf wrote:
> > > > > > For other archs, e.g. x86-64, you can do
> > > > > >
> > > > > > register void *sp asm("%sp");
> > > > > > asm volatile("call func" : "+r"(sp));
On 07/08/2015 02:51 PM, Josh Poimboeuf wrote:
On Wed, Jul 08, 2015 at 11:22:34AM -0500, Josh Poimboeuf wrote:
On Wed, Jul 08, 2015 at 05:36:31AM -0500, Segher Boessenkool wrote:
On Wed, Jul 08, 2015 at 11:23:09AM +0200, Martin Jambor wrote:
For other archs, e.g. x86-64, you can do
reg
On Wed, Jul 08, 2015 at 03:51:12PM -0500, Josh Poimboeuf wrote:
> > > > > For other archs, e.g. x86-64, you can do
> > > > >
> > > > > register void *sp asm("%sp");
> > > > > asm volatile("call func" : "+r"(sp));
>
> I've found that putting "sp" in the clobber list also seems to work:
In the TPF case, the software has to explicitly mark such pointers as
SImode (such things happen only when structures that contain addresses
can't change size, for backwards compatibility reasons[1]):
int * __attribute__((mode(SImode))) ptr;
ptr = &some_var;
so I wouldn't consider this the "d
On 07/08/2015 02:33 PM, DJ Delorie wrote:
Is there any reason that LARL can't be used to load a 32-bit symbolic
value, in 64-bit mode? On TPF (64-bit) the app has the option of
being loaded in the first 4Gb so that all symbols are also valid
32-bit addresses, for backward compatibility. (and if
On Wed, Jul 08, 2015 at 11:22:34AM -0500, Josh Poimboeuf wrote:
> On Wed, Jul 08, 2015 at 05:36:31AM -0500, Segher Boessenkool wrote:
> > On Wed, Jul 08, 2015 at 11:23:09AM +0200, Martin Jambor wrote:
> > > > For other archs, e.g. x86-64, you can do
> > > >
> > > > register void *sp asm("%
Is there any reason that LARL can't be used to load a 32-bit symbolic
value, in 64-bit mode? On TPF (64-bit) the app has the option of
being loaded in the first 4Gb so that all symbols are also valid
32-bit addresses, for backward compatibility. (and if not, the linker
would complain)
Index: s3
On Wed, Jul 08, 2015 at 09:36:43PM +0200, Sebastian Huber wrote:
> from the use cases in libgomp it seems that you may set the value of a
> ptrlock object at most once via gomp_ptrlock_set() if it wasn't already
> initialized to a non-NULL value via gomp_ptrlock_init()? Is this correct?
Please se
Hello,
from the use cases in libgomp it seems that you may set the value of a ptrlock
object at most once via gomp_ptrlock_set() if it wasn't already initialized to
a non-NULL value via gomp_ptrlock_init()? Is this correct?
Why is there a specialized Linux implementation? Is this to save one
> On Jul 8, 2015, at 11:39 AM, André Hentschel wrote:
>
>> Am 07.07.2015 um 23:01 schrieb pins...@gmail.com:
>> What does the elf abi say about x18, I thought it was just another temp. If
>> the target does not use it as a platform reg. Note there are many assembly
>> files which might use
Am 07.07.2015 um 23:01 schrieb pins...@gmail.com:
> What does the elf abi say about x18, I thought it was just another temp. If
> the target does not use it as a platform reg. Note there are many assembly
> files which might use x18 also due to that.
>
> So this means you need wrapper function
On Wed, Jul 08, 2015 at 11:37:35AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 08, 2015 at 11:22:34AM -0500, Josh Poimboeuf wrote:
> > > Writing the asm with a clobber of the stack pointer causes all stack
> > > accesses to go via the frame pointer, which causes pretty horrible
> > > code.
> >
[Abe wrote:]
[snip]
Even without cmove to/from main memory, two cmoves back-to-back with opposite
conditions could still be used, e.g. [not for a real-world ISA]:
load X[x] -> reg1
load Y[y] -> reg2
cmove c ? reg1 -> reg3
cmove (!c) ? reg2 -> reg3
Or even better if the ISA can su
On Wed, Jul 08, 2015 at 11:22:34AM -0500, Josh Poimboeuf wrote:
> > Writing the asm with a clobber of the stack pointer causes all stack
> > accesses to go via the frame pointer, which causes pretty horrible
> > code.
>
> As far as I can tell, most (but not all) kernel stack accesses already
> occ
On Wed, Jul 08, 2015 at 05:36:31AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 08, 2015 at 11:23:09AM +0200, Martin Jambor wrote:
> > > For other archs, e.g. x86-64, you can do
> > >
> > > register void *sp asm("%sp");
> > > asm volatile("call func" : "+r"(sp));
>
>
>
> > Well, I only ha
On Wed, Jul 8, 2015 at 3:18 AM, Sergio Durigan Junior
wrote:
>
> I tried to find the source code of this package, but I could not find
> it. Do you have a URL or something you can provide?
>
Source code is now available at https://github.com/ultragdb/org.eclipse.cdt
--
Xu,Chiheng(徐持恒)
All:
While/For ( condition1)
{
Some code here.
If(condition2 )
continue;
Some code here.
}
Fig(1)
For the above loop in Fig(1) there will be two backedges and multiple latches.
The below code can be transformed to the below in order to
have a single backedge.
While/For (condition
On Wed, Jul 8, 2015 at 12:01 PM, Bin.Cheng wrote:
> On Wed, Jul 8, 2015 at 5:58 PM, Bin.Cheng wrote:
>> On Wed, Jul 8, 2015 at 5:51 PM, Richard Biener
>> wrote:
>>> On Wed, Jul 8, 2015 at 8:52 AM, Bin.Cheng wrote:
Hi,
Function fill_always_executed_in_1 computes basic blocks' always
>>
On Wed, Jul 08, 2015 at 11:23:09AM +0200, Martin Jambor wrote:
> > For other archs, e.g. x86-64, you can do
> >
> > register void *sp asm("%sp");
> > asm volatile("call func" : "+r"(sp));
> Well, I only have had a quick look at where things "go wrong" and have
> not spent much time thin
On Wed, Jul 8, 2015 at 5:58 PM, Bin.Cheng wrote:
> On Wed, Jul 8, 2015 at 5:51 PM, Richard Biener
> wrote:
>> On Wed, Jul 8, 2015 at 8:52 AM, Bin.Cheng wrote:
>>> Hi,
>>> Function fill_always_executed_in_1 computes basic blocks' always
>>> executed information, and it has below code and comment:
On Wed, Jul 8, 2015 at 5:51 PM, Richard Biener
wrote:
> On Wed, Jul 8, 2015 at 8:52 AM, Bin.Cheng wrote:
>> Hi,
>> Function fill_always_executed_in_1 computes basic blocks' always
>> executed information, and it has below code and comment:
>>
>> /* In a loop that is always entered we ma
Abe wrote:
[snip]
Predication of instructions can help to remove the burden of the conditional
branch, but is not available on all relevant architectures.
In some architectures that are typically implemented in modern high-speed
processors -- i.e. with high core frequency, caches, speculative e
On Wed, Jul 8, 2015 at 8:52 AM, Bin.Cheng wrote:
> Hi,
> Function fill_always_executed_in_1 computes basic blocks' always
> executed information, and it has below code and comment:
>
> /* In a loop that is always entered we may proceed anyway.
> But record that we entered it and
On Tue, Jul 07, 2015 at 02:25:34PM -0600, Jeff Law wrote:
> On 07/07/2015 11:53 AM, Martin Jambor wrote:
> >Hi,
> >
> >I've been asked to look into the item one of
> >http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out
> >that at least shrink-wrapping happily moves prologue past an
Hi,
On Tue, Jul 07, 2015 at 01:44:15PM -0500, Segher Boessenkool wrote:
> On Tue, Jul 07, 2015 at 07:53:49PM +0200, Martin Jambor wrote:
> > I've been asked to look into the item one of
> > http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out
> > that at least shrink-wrapping happil
29 matches
Mail list logo
