On Mon, Jul 06, 2009 at 02:35:13PM -0700, Brian O'Mahoney wrote:
> Re: -print-* command-line switches misbehave or are misdocumented
>
> Why not just fix it, if not document the way it works, cutsie, "its a
> developer feature" fools no one and just hands ammunition to the
> anti Linux and GNU cam
Re: -print-* command-line switches misbehave or are misdocumented
Why not just fix it, if not document the way it works, cutsie, "its a
developer feature" fools no one and just hands ammunition to the
anti Linux and GNU camp, they read these lists too!
--
Greetings Brian
Trevor Scroggins writes:
> No, that won't work. The assembler only recognizes .text, .data, and
> .bss and doesn't support .section. Surely there's a simple hook that
> instructs that compiler to print locals after a function instead of
> before it?
No. Why should there be? Even if you fix the
No, that won't work. The assembler only recognizes .text, .data, and
.bss and doesn't support .section. Surely there's a simple hook that
instructs that compiler to print locals after a function instead of
before it?
On Mon, Jul 6, 2009 at 10:11 AM, Trevor
Scroggins wrote:
> The target doesn't use
Rainer Emrich writes:
> At least on cygwin --with-host-libstdcxx doesn't work as expected.
>
> ../gcc/configure --with-host-libstdcxx=-lstdc++
> gives
> POSTSTAGE1_LIBS =
> in the top Makefile.
>
> ../gcc/configure --with-boot-libs=-lstdc++
> gives
> POSTSTAGE1_LIBS = -lstdc++
> in the top Makefi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
At least on cygwin --with-host-libstdcxx doesn't work as expected.
../gcc/configure --with-host-libstdcxx=-lstdc++
gives
POSTSTAGE1_LIBS =
in the top Makefile.
../gcc/configure --with-boot-libs=-lstdc++
gives
POSTSTAGE1_LIBS = -lstdc++
in the top Mak
Sorry about the delay in the answer (4th of July weekend...).
Anyway, I agree it might not be necessary. I put it there because of
the force_reg call. Since that call might in turn call gen_reg_rtx, it
will then start off with an assertion of can_create_pseudo_p.
That is why, I thought best to pu
The target doesn't use ELF. I have .text, .data, and .bss, and
read-only data normally goes in .text. I'm learning as I go, so I'll
fiddle with a dummy .rodata section of some sort that the linker can
position accordingly.
On Mon, Jul 6, 2009 at 10:00 AM, Ian Lance Taylor wrote:
> Most targets put
Trevor Scroggins writes:
> What I'd like to do is place all constant and read-only data, which I
> now think means all data affected by CONSTANT_POOL_BEFORE_FUNCTION and
> READONLY_DATA_SECTION_ASM_OP (and others?); however, I'd like local,
> read-only data--strings and whatnot--to stay in .text,
Hello.
I've submitted patches (and had them OK'd) to add support for FreeBSD on
x86_64 [1] and, as you can see, have been told that I need SVN write access
and (according the site [2]) a copyright assignment or a dedication of
work to the public domain.
Exactly how do I go about organising the ab
I guess I'm not understanding the usage of the term constant pool.
What I'd like to do is place all constant and read-only data, which I
now think means all data affected by CONSTANT_POOL_BEFORE_FUNCTION and
READONLY_DATA_SECTION_ASM_OP (and others?); however, I'd like local,
read-only data--string
* Joel Sherrill, 2009-07-06 :
> It got tripped because newlib-cvs has been reworked and
> a number of errno's conditionalized as Linux specific. I was
> enabling the ones which were also used by RTEMS via
> the BSD TCP/IP stack.
>
> Some were not used by RTEMS so I left them turned off.
OK, und
Thomas Quinot wrote:
* Laurent GUERBY, 2009-07-04 :
Apparently no one has hit this case. RTEMS does
not have two error codes that g-socket.adb
maps back. From s-oscons.ads:
ESHUTDOWN : constant := -1; -- Cannot send once
shutdown
ESOCKTNOSUPPORT : constant :=
* Laurent GUERBY, 2009-07-04 :
> > Apparently no one has hit this case. RTEMS does
> > not have two error codes that g-socket.adb
> > maps back. From s-oscons.ads:
> >
> >ESHUTDOWN : constant := -1; -- Cannot send once
> > shutdown
> >ESOCKTNOSUPPORT : constant :
Hello All
I would suppose that the preprocessor (ie libcpp) might be enhanced to
use plugins. I can see several scenarii for them:
1. a plugin could enhance the way #include directives are processed
2. a plugin could add additional builtin macros, like __COUNTER__, which
would be specific to
15 matches
Mail list logo
