preprocessors & GCC plugins
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 the plugin.
3. a plugin could add extra CPP directives (like #ident)
What do you think? Probably 1 is harder to implement than 2 or 3, but I
am not very familiar with libcpp/
The http://gcc.gnu.org/ml/gcc/2009-07/msg9.html mail suggested me
the plugins could be useful in the preprocessor.
Currently, there is no plugin specific code inside libcpp/
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***
Re: g-socket.adb error
* 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 := -1; -- Socket type not > > supported > > > > This results in a compilation error in g-socket.adb > > in the switch since they both have the same value: > > > > g-socket.adb:1775:15: duplication of choice value at line 1773 I really wonder how nobody stumbled on this in the past since this code has been essentially untouched for a very long time. Is it really the case that both ESHUTDOWN and ESOCKTNOSUPPORT are undefined in RTEMS (as in, has this been checked manually in errno.h, and can't proper definitions be given there???) > Just above the case there is already one case of duplicate > error code handled by an explicit "if" instead of "case": > > if EAGAIN /= EWOULDBLOCK and then Error_Value = EAGAIN then > return Resource_Temporarily_Unavailable; > end if; > > I guess moving from case to if would be an appropriate way to fix > this RTEMS issue (assuming this is the only conflict), Thomas is in Cc. I'm not very happy with this proposal, since the chain of IF statements would be much less efficient than the CASE (which currently generates an indexed jump). What we could do would be to build an array mapping errno to Error_Type values at initialization time, and then index that array (however that means we'd have to know the maximum range of errnos). Or alternatively we could assign distinct junk invalid values to ESHUTDOWN and ESOCKNOTSUPPORT in s-oscons-tmplt.c (eg -1 and -2, instead of -1 for both). Thomas. -- Thomas Quinot, Ph.D. ** qui...@adacore.com ** Senior Software Engineer AdaCore -- Paris, France -- New York, USA
Re: g-socket.adb error
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 := -1; -- Socket type not supported This results in a compilation error in g-socket.adb in the switch since they both have the same value: g-socket.adb:1775:15: duplication of choice value at line 1773 I really wonder how nobody stumbled on this in the past since this code has been essentially untouched for a very long time. Is it really the case that both ESHUTDOWN and ESOCKTNOSUPPORT are undefined in RTEMS (as in, has this been checked manually in errno.h, and can't proper definitions be given there???) Just above the case there is already one case of duplicate error code handled by an explicit "if" instead of "case": if EAGAIN /= EWOULDBLOCK and then Error_Value = EAGAIN then return Resource_Temporarily_Unavailable; end if; I guess moving from case to if would be an appropriate way to fix this RTEMS issue (assuming this is the only conflict), Thomas is in Cc. I'm not very happy with this proposal, since the chain of IF statements would be much less efficient than the CASE (which currently generates an indexed jump). What we could do would be to build an array mapping errno to Error_Type values at initialization time, and then index that array (however that means we'd have to know the maximum range of errnos). 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. Or alternatively we could assign distinct junk invalid values to ESHUTDOWN and ESOCKNOTSUPPORT in s-oscons-tmplt.c (eg -1 and -2, instead of -1 for both). I don't care particularly what the solution is. Whatever you think is best. :) Thomas. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: g-socket.adb error
* 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, understood, so my advice would be to resurrect in newlib those errno values that are known by g-socket so that they have distinct values. Thomas. -- Thomas Quinot, Ph.D. ** qui...@adacore.com ** Senior Software Engineer AdaCore -- Paris, France -- New York, USA
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
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--strings and whatnot--to stay in .text, stored after the function rather than prior to it. More specifically, the data should be stored in a location appropriate for the addressing mode, as long as that location is not before the first instruction in .text. e.g.: .text # NOT HERE .even .globl_main _main: ... rts # HERE LC0: .ascii "this is a string\0" LC1: .ascii "this is another string\0" Will I need to "optimize" the location of the data myself? On Sun, Jul 5, 2009 at 11:14 PM, Ian Lance Taylor wrote: > Setting CONSTANT_POOL_BEFORE_FUNCTION to 0 ought to work to emit the > constant pool after the function. However, to be clear, it only affects > the constant pool which holds constants which are not > LEGITIMATE_CONSTANT_P. This is normally things like 32-bit constants > which RISC architectures can not handle in a single instruction. The > m68k is a flexible architecture and can handle 32-bit constants just > fine without using a constant pool. You didn't really describe what you > are seeing; what makes you think that the constant pool is the problem?
Becoming maintainer of FreeBSD x86_64 GNAT port
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 above? The documentation linked to on the FSF site is convoluted and not helpful. I'm fully prepared to dedicate every single line I write to the public domain. I'm solely interested in getting a working compiler - not in copyright, credit, licensing or any other distractions. Regards, M [1] http://gcc.gnu.org/ml/gcc-patches/2009-07/msg00102.html [2] http://gcc.gnu.org/contribute.html#legal
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
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, stored after > the function rather than prior to it. More specifically, the data > should be stored in a location appropriate for the addressing mode, as > long as that location is not before the first instruction in .text. > e.g.: > > .text > # NOT HERE > .even > .globl_main > _main: > ... > rts > # HERE > LC0: > .ascii "this is a string\0" > LC1: > .ascii "this is another string\0" > > Will I need to "optimize" the location of the data myself? Most targets put constant strings and the like in the .rodata section. Then the linker script can put that in a useful place. That seems like the best approach to use for a processor like m68k which supports general addressing. I'm surprised that doesn't happen already. I assume you are using an ELF target, in which case I would expect default_elf_select_rtx_section to do the right thing. Ian
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
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 constant strings and the like in the .rodata section. > Then the linker script can put that in a useful place. That seems like > the best approach to use for a processor like m68k which supports > general addressing. I'm surprised that doesn't happen already. I > assume you are using an ELF target, in which case I would expect > default_elf_select_rtx_section to do the right thing. > > Ian >
Re: Immediates propagated wrongly in stores
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 put that test.
On Wed, Jul 1, 2009 at 5:33 PM, Richard Henderson wrote:
> On 07/01/2009 02:02 PM, Jean Christophe Beyler wrote:
>>
>> ((reload_in_progress | reload_completed) == 0&&
>> MEM_P (op0)&& !REG_P (op1)))
>> {
>> op1 = force_reg (GET_MODE (op0), op1);
>> emit_move_insn (op0, op1);
>> return 1;
>
> I wouldn't think you'd actually need these reload checks.
> At least some other ports I glanced at don't need them.
>
>
> r~
>
--with-host-libstdcxx doesn't work as expected
-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 Makefile. The docs say: - --with-boot-libs=libs This option may be used to set libraries to be used when linking stage 2 and later when bootstrapping GCC. The default is the argument to - --with-host-libstdcxx, if specified. So, that's not true. Rainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpSNpkACgkQoUhjsh59BL5PSgCfXStHvaGmgo42X7EDhfP1hSuK ZakAoJNE08cGZ3jeMODIZ2D2SsOtujBc =T10u -END PGP SIGNATURE-
Re: --with-host-libstdcxx doesn't work as expected
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 Makefile. > > The docs say: > > --with-boot-libs=libs > This option may be used to set libraries to be used when linking stage 2 > and > later when bootstrapping GCC. The default is the argument to > --with-host-libstdcxx, if specified. > > So, that's not true. Sorry about that. There was a missing comma in configure.ac. Fixed as follows (also fixed indentation). Committed as obvious. Ian 2009-07-06 Ian Lance Taylor * configure.ac: Add missing comma in AC_ARG_WITH(boot-libs). * configure: Rebuild. Index: configure.ac === --- configure.ac (revision 149291) +++ configure.ac (working copy) @@ -1468,11 +1468,11 @@ AC_SUBST(poststage1_ldflags) # Libraries to use for stage2 and later builds. This defaults to the # argument passed to --with-host-libstdcxx. AC_ARG_WITH(boot-libs, -[ --with-boot-libs=LIBS Libraries for stage2 and later] +[ --with-boot-libs=LIBS Libraries for stage2 and later], [if test "$withval" = "no" -o "$withval" = "yes"; then poststage1_libs= else - poststage1_libs=$withval + poststage1_libs=$withval fi], [poststage1_libs=$with_host_libstdcxx]) AC_SUBST(poststage1_libs)
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
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 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 constant strings and the like in the .rodata section. >> Then the linker script can put that in a useful place. That seems like >> the best approach to use for a processor like m68k which supports >> general addressing. I'm surprised that doesn't happen already. I >> assume you are using an ELF target, in which case I would expect >> default_elf_select_rtx_section to do the right thing. >> >> Ian >> >
Re: CONSTANT_POOL_BEFORE_FUNCTION has no effect in tm.h?
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 case of string constants,
you will run into trouble as soon as somebody writes
const int ai[] = { 1 };
Most systems require some sort of startup code to run before main,
anyhow. If you have no such requirement, then I recommend simply being
disciplined in how you write the "main" function, or paying the cost of
two or four initial bytes to branch to the main function from the start
of the .text section.
Ian
Re: -print-* command-line switches misbehave or are misdocumented
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
Re: -print-* command-line switches misbehave or are misdocumented
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 camp, they read these lists too! Patches are welcome.
