Marek,
Your response is MOST helpful. THANK YOU!
Regards,
George...
- Original Message -
From: Marek Polacek
To: George R Goffe
Cc: "gcc@gcc.gnu.org"
Sent: Monday, August 5, 2013 10:16 PM
Subject: Re: c++/linker problems maybe?
On Mon, Aug 05, 2013 at 10:05:22PM -0700, George R G
On Mon, 2013-08-05 at 11:49 -0700, Linus Torvalds wrote:
> Ugh. Why the crazy update_jump_label script stuff?
After playing with the patches again, I now understand why I did that.
It wasn't just for optimization.
Currently the way jump labels work is that we use asm goto() and place a
5 byte no
Hi all,
I am form RTEMS org, recently we are working on atomic support for RTEMS. The
C11 stdatomic.h has been ported to RTEMS. But when i build the atomic test case
for pc686 BSP it will post some error like this :
/home/rtems-build/i386-build/i386-rtems4.11/c/pc686/testsuites/smptests/smpatom
On 6 August 2013 15:47, Deng Hengyi wrote:
>
> And i have found some mail list talking about gcc has remove lock free atomic
> int support [1][2], is this true? or just some error caused by my toolchain?
>
> I am waiting for your reply, Thank you!
>
>
> [1]. http://gcc.gnu.org/ml/gcc/2012-12/msg00
Hi Jonathan,
Thank you for your reply.
And about the error i encounter, do you have any advice? maybe it is caused by
my toolchain not install rightly?
In the standard pc686 architecture(not cross compile on RTEMS) will it
encounter the similar error?
WeiY
Best Regards
在 2013-8-6，下午11:25，Jona
On Mon, 2013-08-05 at 15:03 +0100, Richard Sandiford wrote:
> Sorry for the long mail and for what's probably an FAQ. I did try to find
> an answer without bothering the list... (and showing my ignorance so much :-))
>
> At the moment, the s390 backend treats all atomic loads as simple loads
> an
On 6 August 2013 16:30, Deng Hengyi wrote:
> Hi Jonathan,
>
> Thank you for your reply.
> And about the error i encounter, do you have any advice? maybe it is caused
> by my toolchain not install rightly?
> In the standard pc686 architecture(not cross compile on RTEMS) will it
> encounter the sim
On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
> For unconditional jmp that should be pretty safe barring any fundamental
> changes to the instruction set, in which case we can enable it as
> needed, but for extra robustness it probably should skip prefix bytes.
Would the assembler add
On 08/06/2013 09:15 AM, Steven Rostedt wrote:
> On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
>
>> For unconditional jmp that should be pretty safe barring any fundamental
>> changes to the instruction set, in which case we can enable it as
>> needed, but for extra robustness it probabl
On Tue, 2013-08-06 at 09:19 -0700, H. Peter Anvin wrote:
> On 08/06/2013 09:15 AM, Steven Rostedt wrote:
> > On Mon, 2013-08-05 at 14:43 -0700, H. Peter Anvin wrote:
> >
> >> For unconditional jmp that should be pretty safe barring any fundamental
> >> changes to the instruction set, in which case
On 08/06/2013 09:26 AM, Steven Rostedt wrote:
>>
>> No, but if we ever end up doing MPX in the kernel, for example, we would
>> have to put an MPX prefix on the jmp.
>
> Well then we just have to update the rest of the jump label code :-)
>
For MPX in the kernel, this would be a small part of th
On Tue, Aug 6, 2013 at 7:19 AM, Steven Rostedt wrote:
>
> After playing with the patches again, I now understand why I did that.
> It wasn't just for optimization.
[explanation snipped]
> Anyway, if you feel that update_jump_label is too complex, I can go the
> "update at early boot" route and s
On Tue, 2013-08-06 at 10:48 -0700, Linus Torvalds wrote:
> So I wonder if this is a "ok, let's not bother, it's not worth the
> pain" issue. 128 bytes of offset is very small, so there probably
> aren't all that many cases that would use it.
OK, I'll forward port the original patches for the hell
Hi,
i386elf.h defines:
/* The ELF ABI for the i386 says that records and unions are returned
in memory. */
#define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \
(TYPE_MODE (TYPE) == BLKmode \
|| (VECTOR_MODE_P (TYPE_MODE (TYPE)) && int_size_in_bytes (TYPE) == 8))
and as such d
On Tue, Aug 6, 2013 at 1:46 PM, Nathan Sidwell wrote:
> Hi,
> i386elf.h defines:
>
> /* The ELF ABI for the i386 says that records and unions are returned
>in memory. */
>
> #define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \
> (TYPE_MODE (TYPE) == BLKmode \
> || (VECTOR_MODE_
* Steven Rostedt (rost...@goodmis.org) wrote:
> On Tue, 2013-08-06 at 10:48 -0700, Linus Torvalds wrote:
>
> > So I wonder if this is a "ok, let's not bother, it's not worth the
> > pain" issue. 128 bytes of offset is very small, so there probably
> > aren't all that many cases that would use it.
Hi!
Since some time, I'm running compile tests for binutils/gdb/gcc on
three of my machines. As you noticed, they're hitting errors from time
to time.
So I decided to spend it a small web frontend:
http://toolchain.lug-owl.de/buildbot/
Maybe it's useful to somebody.
MfG, JBG
--
On Tue, 2013-08-06 at 16:33 -0400, Mathieu Desnoyers wrote:
> Steve, perhaps you could add a mode to your binary rewriting program
> that counts the number of 2-byte vs 5-byte jumps found, and if possible
> get a breakdown of those per subsystem ?
I actually started doing that, as I was curious t
On 22 July 2013 21:39, Jason Merrill wrote:
> I'd like to make some changes to the GCC git-svn mirror. Specifically, I
> want to move all the SVN branches from remotes/ into heads/ and split the
> subdirectory branches (redhat, google, etc) into the individual branches.
>
> Should I leave the SVN
On 7 August 2013 00:56, Jonathan Wakely wrote:
> On 22 July 2013 21:39, Jason Merrill wrote:
>> I'd like to make some changes to the GCC git-svn mirror. Specifically, I
>> want to move all the SVN branches from remotes/ into heads/ and split the
>> subdirectory branches (redhat, google, etc) into
On Tue, 2013-08-06 at 16:43 -0400, Steven Rostedt wrote:
> On Tue, 2013-08-06 at 16:33 -0400, Mathieu Desnoyers wrote:
>
> > Steve, perhaps you could add a mode to your binary rewriting program
> > that counts the number of 2-byte vs 5-byte jumps found, and if possible
> > get a breakdown of those
On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote:
> [3.387362] short jumps: 106
> [3.390277] long jumps: 330
>
> Thus, approximately 25%. Not bad.
Also, where these happen to be is probably even more important than how
many. If all the short jumps happen in slow paths, it's rathe
On Tue, Aug 06, 2013 at 08:56:00PM -0400, Steven Rostedt wrote:
> On Tue, 2013-08-06 at 20:45 -0400, Steven Rostedt wrote:
>
> > [3.387362] short jumps: 106
> > [3.390277] long jumps: 330
> >
> > Thus, approximately 25%. Not bad.
>
> Also, where these happen to be is probably even more
23 matches
Mail list logo
