- Moving pairs
Given something like a checkers board, moving pairs would be checker pieces
paired together and arranged on the board so they each checker piece
is said to be paired with another.
The pairs don't have to be next to eachother, they can arrange on the
board in any awy.
Any way arran
good day Nick:
Pablo Bleyer Kocik has built GCC 4.2.2 and i am testing this for
the previous 2 bugs - 6726, 6727 - that i reported.
i have one question for you: apparently, in 2003, you made a change
to prevent -mno-fpu from being passed to GAS.
ARM: Do not pass -mno-fpu to the assembler
http:/
good evening Nick:
i checked and the veneer code generation problem described in
SourceWare BugZilla bug 6727 has not yet been fixed in binutils-2.18,
and that's the latest stable release.
lets see if i can get the latest sources from CVS and then if i
can build and use it.
i will get back to y
Hello,
I came across a problem related to cross-section inlining. For the
following example,
static void foo(void) __attribute__((section ("foo")));
static void foo(void)
{
printf("Hello\n");
}
void bar(void) __attribute__((section ("bar")));
void bar(void)
{
foo();
}
I compiled wi
Hi all, hi Joseph,
on x86_64-linux I'm seeing many new warnings which didn't exist until a few
days ago, see below.
Is that known? Joseph, can it have something to do with your recent libsupc++
changes?
Thanks,
Paolo.
//
../../../../trunk/libstdc++-v3/libsupc++/eh_personalit
On Wed, Jul 23, 2008 at 4:46 PM, Bingfeng Mei <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I came across a problem related to cross-section inlining. For the
> following example,
>
> static void foo(void) __attribute__((section ("foo")));
>
> static void foo(void)
> {
> printf("Hello\n");
> }
>
> void
Bingfeng Mei wrote on 23 July 2008 15:46:
> The foo function is inlined into bar anyway even they have different
> section attribute. Is this a bug or expected behaviour?
Well, I would expect it, but only in the light of knowing how the compiler
works.
Sections are outside the scope of the
Paolo Carlini wrote:
Hi all, hi Joseph,
on x86_64-linux I'm seeing many new warnings which didn't exist until a few
days ago, see below.
Is that known? Joseph, can it have something to do with your recent libsupc++
changes?
I noticed them too. These warnings say that the unwind-cxx.h
dec
Thanks. I know how to use "noinline" to avoid inlining. Just our
application programmers expect the different sections guarantee that
these functions won't be compiled into same section, therefore should
never be inlined. It took a while for us to find this problem.
Cheers,
Bingfeng
> -Origi
Hi,
> However, a svn log shows that neither unwind-cxx.h nor except.c
> in the C++ frontend changed this year in a relevant way. So my guess
> is that the warning is what changed. Either the warning settings during
> compilation, or a new warning was introduced/activated in the
> compiler itself.
... I see this comment in except.c:do_begin_catch:
/* Declare void* __cxa_begin_catch (void *). */
Instead, in libstdc++/libsup++/unwind-cxx.h:
extern "C" void *__cxa_begin_catch (void *) throw();
So, who is right? Note, the symbol is exported, I'm not suer which headroom for
chan
Hi, I am doing research on optimization of microprocessors and
compilers. Some of you already know my optimization manuals
(www.agner.org/optimize/).
I have tested many different compilers and compared how well they
optimize C++ code. I have been pleased to observe that gcc has been
improved
Agner Fog wrote:
I have tested a few of the most important functions in
libc and compared them with other available libraries (MS, Borland,
Intel, Mac). The comparison does not look good for gnu libc. See my test
results in http://www.agner.org/optimize/optimizing_cpp.pdf section 2.6.
As far
Paolo Carlini wrote:
... I see this comment in except.c:do_begin_catch:
/* Declare void* __cxa_begin_catch (void *). */
Instead, in libstdc++/libsup++/unwind-cxx.h:
extern "C" void *__cxa_begin_catch (void *) throw();
So, who is right? Note, the symbol is exported, I'm not suer w
Say pieces on a board, make each a pair with another piece.
like...
|55|44|66|
|44|66|55|
so figure out how a piece can move.
pick any piece, try to move it somewhere.
when you move a piece you have to move it's pair at the same time.
when you move to a piece it's pair has to move at the same t
Hi Mark,
> This is not an ABI issue; the presence of absence of an
> exception-specifier does not affect the ABI.
Yes, I realized in the meanwhile, via my usual layman investigations using nm.
[snip explanation]
Ok. Actually I can clearly remember when you advertised the use of throw()
whenev
Paolo Carlini wrote:
Now, however, I'm not sure to understand which kind of way forward
you can see... Should the warning machinery be smart enough to not
warn at all in this case? Or? Sorry, probably it's just my ignorance
about those issues at the interface between core and library, I would
re
> Does that help?
Totally ;) And, for what is worth, I totally agree with your analysis.
Essentially, as far as I can see, only a TREE_NOTHROW (fn): line in
except.c:do_begin_catch is missing to complete the "baseline project" ;) Patch
forthcoming (I hope)
Thanks!
Paolo.
Jason mclaughlin wrote:
Say pieces on a board, make each a pair with another piece.
like...
|55|44|66|
|44|66|55|
so figure out how a piece can move.
This is the second post I've seen like this - and no responses.
What is the proposed value of this line of thinking? Is there some
partic
hello:
this is FYI from Nick Clifton in response to my query regarding
deprecation of -mno-fpu for ARM GAS. in the response, the list
was not CC'd by mistake.
Aaron
Original Message
Subject : Re: [Fwd: QUERY : why is -mno-fpu deprecated when we need
it for integer
... just to keep you updated, I'm finishing testing the below, appears to work
well. Still missing: comments about ABI (no throw()) vs our specific libsupc++
implementation (suggestions very welcome ;)
Paolo.
//
Index: except.c
===
Nothing interesting except less regressions. Yay.
Snapshot gcc-4.2-20080723 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080723/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Wed, Jul 23, 2008 at 12:15 PM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Hi, I am doing research on optimization of microprocessors and compilers.
> Some of you already know my optimization manuals (www.agner.org/optimize/).
Sorry but I'm not buying.
The Sun Studio 12 compiler with Solaris 10 on
can't a machine always be seen where every part of the machine is one
way, for another part to be one way?
i mean... say you can take a bunch of parts and have it so each part
has only one way to be.
then parts can be together, where they fit the way that each part can
only be one way for the way
25 matches
Mail list logo
