On 10/02/2010 01:50 PM, Rodrigo Rivas wrote:
I would change cp_parser_range_for to use cp_parser_decl_specifier_seq
> instead of cp_parser_type_specifier_seq and then wait to complain about
> defining a type until after we've seen the ':'.
I already tried that, but it didn't work. It seemed to m
On Mon, 4 Oct 2010, FX wrote:
> The attached patch is my first attempt to deal with
> TARGET_CPU_CPP_BUILTINS macros by splitting them into
> language-independent and C-family parts. This is now more like a
> demonstration of how I intend to proceed, by creating a new macro
> TARGET_CPU_CPP_BU
Phung Nguyen schrieb:
> Dear Georg,
>
> Thank you for your help.
>
> I have a problem after I follow your way. When I compile newlib with
> the modified (in the way you did in blackfin) way, I got the error
> message:
> In function "fopencookie":newlib/libc/stdio/fopencookie.c: 261: error,
> insn
Hello,
in the linux kernel I defined a function as follows:
static struct platform_device *__init __maybe_unused
imx_add_imx_dma(void)
{
...
}
and the only used was #ifdefed out.
With the following defines:
#define __section(S) __attribute__ ((_
Hi,
>> Nick, Naveen, the diff between the GCC and the src commits is this;
>> which variant is correct?
>> -noconfigdirs="$noconfigdirs target-libgloss ${libgcj}"
>> +noconfigdirs="$noconfigdirs ${libgcj}"
The following variant in src is the correct version:-
+noconfigdirs="$noconfigd
Hi All,
Do we have a mechanism to map a tree or gimple to a series of
properties so that we can transfer information from one pass to another?
Thanks,
Hongtao
Purdue Univeristy
The attached patch is my first attempt to deal with TARGET_CPU_CPP_BUILTINS
macros by splitting them into language-independent and C-family parts. This is
now more like a demonstration of how I intend to proceed, by creating a new
macro TARGET_CPU_CPP_BUILTINS_CFAMILY. Also, it shows how I proce
On Mon, Oct 4, 2010 at 4:43 PM, Hongtao wrote:
> Hi All,
>
> Do we have a mechanism to map a tree or gimple to a series of
> properties so that we can transfer information from one pass to another?
No.
> Thanks,
> Hongtao
> Purdue Univeristy
>
> Ah, yes. So we should share the parsing of the decl-specifier-seq with the
> C-style for loop, which allows us to avoid the tentative parsing.
That was my original idea, but the C-style loop calls
cp_parser_simple_declaration(), that shouts at the ':'. So we should
either modify it to accept the
On Mon, 4 Oct 2010 16:47:00 +0200
Richard Guenther wrote:
> On Mon, Oct 4, 2010 at 4:43 PM, Hongtao wrote:
> > Hi All,
> >
> > Do we have a mechanism to map a tree or gimple to a series of
> > properties so that we can transfer information from one pass to another?
MELT does provide that, but
On 09/17/2010 02:25 AM, Ed Smith-Rowland wrote:
I am slowly working on user defined literals for C++-0x.
Thanks! Please send future patches to gcc-patches and me directly.
Looking over your patch, I see you're doing a significant amount of it
in the parser, which is incorrect; the draft says
On 10/04/2010 10:59 AM, Rodrigo Rivas wrote:
Admittedly, this is not a "trailing_return_type", but AFAICT it has
exactly the same restrictions.
The restrictions are slightly different; in the case of a trailing return
type a class-specifier is not one of the expansions, so we don't treat a {
as
>> Ah, yes. So we should share the parsing of the decl-specifier-seq with the
>> C-style for loop, which allows us to avoid the tentative parsing.
>
> That was my original idea, but the C-style loop calls
> cp_parser_simple_declaration(), that shouts at the ':'. So we should
> either modify it to
> I would like to reduce this to
>
> STACK_BOUNDARY
>
> -- minimum alignment enforced by hardware.
>...
> -- unchanged
This may be determined by factors other than hardware. For example the ARM
EABI requires that the stack be 8-byte aligned at public entry points. However
within a functio
On 10/04/2010 11:00 AM, Paul Brook wrote:
> Your proposal doesn't make this problem any worse, if anything it's better
> because we don't have to device between S_B and PREFERRED_STACK_BOUNDARY. I'm
> just noting that documenting this as a hardware property is at best
> misleading.
Well, I'm ho
Oct 4, 2010 11:26:15 AM, ja...@redhat.com wrote:
>On 09/17/2010 02:25 AM, Ed Smith-Rowland wrote:
>> I am slowly working on user defined literals for C++-0x.
>
>Thanks! Please send future patches to gcc-patches and me directly.
>
>Looking over your patch, I see you're doing a significant amount o
Uwe Kleine-König writes:
> in the linux kernel I defined a function as follows:
>
> static struct platform_device *__init __maybe_unused
> imx_add_imx_dma(void)
> {
> ...
> }
>
> and the only used was #ifdefed out.
>
> With the following defines:
>
> #define
On 10/02/2010 04:03 PM, H.J. Lu wrote:
>> MIN_STACK_BOUNDARY
>> (undocumented; local to i386 atm)
>> -- appears to be the ABI specified stack boundary, i.e.
>> the minimum that must be in place at a call site. This
>> somehow differs from I_S_B due to proliferation of
>> command-line options.
On Mon, Oct 4, 2010 at 7:16 PM, Nicola Pero
wrote:
> I just implemented "fast enumeration" (ie, "for (object in array) { ... }")
> for Objective-C, and I was now planning on doing it for Objective-C++ too. ;-)
>
> If you're doing range-based for-loops for C++, we may as well share ideas ;-)
Actual
On 10/04/2010 02:16 PM, 3dw...@verizon.net wrote:
You shouldn't be able to call it as just _foo(1.2L); an operator name is
different from a normal function name.
According to 13.5.8/7 :
[ Note: literal operators and literal operator templates are usually invoked
implicitly through user-defi
> I don't think you need define_target_specific_builtins as part of the
> public interface to cppbuiltin.c; it will always be called along with
> define_language_independent_builtin_macros so may as well be called
> internally by that function (which could gain an iso_c parameter for that
> pur
> > Your proposal doesn't make this problem any worse, if anything it's
> > better because we don't have to device between S_B and
> > PREFERRED_STACK_BOUNDARY. I'm just noting that documenting this as a
> > hardware property is at best misleading.
>
> Well, I'm hoping to document that it *is* a h
On Mon, Oct 4, 2010 at 11:27 AM, Richard Henderson wrote:
> On 10/02/2010 04:03 PM, H.J. Lu wrote:
>>> MIN_STACK_BOUNDARY
>>> (undocumented; local to i386 atm)
>>> -- appears to be the ABI specified stack boundary, i.e.
>>> the minimum that must be in place at a call site. This
>>> somehow di
* Frédéric Buclin:
> If nothing severe is found in the coming days, we will probably upgrade
> the production installation later this week. I think Ian will keep you
> informed about this.
It seems that the new Bugzilla does not set a Message-ID header when
sending mail. While this is not a viol
Hello,
* FX wrote on Sun, Oct 03, 2010 at 11:22:50AM CEST:
> > This is a known issue and related to timestamps of those generated
> > .texi files. By touching generated .texi it can be solved.
Hacked around, I would say, not solved.
I guess to solve it, genhooks should produce output in binary m
Le 05. 10. 10 06:53, Florian Weimer a écrit :
> It seems that the new Bugzilla does not set a Message-ID header when
> sending mail.
You come a bit late in the game, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45818 ;)
Frédéric
26 matches
Mail list logo
