Re: Range-based for in c++98

[Jason Merrill]

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 me that it was
because it called cp_parser_commit_to_tentative_parse(), and if then I
wanted to roll-back the parsing of the range-for, I went badly. I had
to agree with Manuel that the tentative parsing is a bit messy...


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.



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 beginning a class body.  In the case of a 
type-specifier-seq, we do treat it as beginning a class body, but we 
give an error about it.


Jason

Re: [RFC] Dealing with TARGET_CPU_CPP_BUILTINS

[Joseph S. Myers]

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_BUILTINS_CFAMILY. Also, it shows how I proceed for the 
> case of targets that employ a worker function (which thus does fully 
> belong to, e.g., i386-c.c anymore).

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 
purpose).

I suppose calling cpp_define directly in target .c files (and generally 
not having a separate set of preprocessor-using-front-end-hooks) is safe 
in that all front ends are linked with cpplib, though I think the reason 
they are so linked at present is just for the line-map code.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: How to get attribute of callee

[Georg Lay]

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 does not satisfy its constraints:
> (set (reg:HI 5 r5) (reg:HI 19 virtual-outgoing-args) 5 {*movhi_large}
> (nil) (nil))
> 
> internal compiler error: in reload_cse_simplify_operands, at postreload.c:391

Please open new questions in the gcc resp. gcc-help mailing lists for new 
issues.

Please write to the gcc's lists. Other guy might learn from the lists, there is
no reason for private communication.

> Did you get the similar problem? Or do you have any idea???

The problem arises from your movhi-insn implementation. Obviously, you try to
split several cases of move by means of predicates/conditions. Don't do that.
You will have to handle every alternative in the constraints, anyway, so this
leads mainly to duplications of insns (and much of trouble until you got there,
especially by register allocator freaking in corner cases).

Supply ONE move insn per mode an fix architecture's oddities and
non-orthogonalities in its constraints.

> Best regards,
> Phung

Georg

about function attributes for functions returning a pointer

[Uwe Kleine-König]

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__ ((__section__(#S)))
#define __cold __attribute__((__cold__))
#define notrace __attribute__((no_instrument_function))
#define __init  __section(.init.text) __cold notrace
#define __maybe_unused  __attribute__((unused))

this still generated the "defined but unused" warning.

Then after changing the definition to

static struct platform_device __init __maybe_unused 
*imx_add_imx_dma(void)

(i.e. move the * after the attribute stuff) the warning is gone.  In
both cases (and when the function was used) it is put in the
".init.text" section though.  That is in the first case __init worked,
but __maybe_unused did not.  Is this intended?  Do I something wrong?
What is the most correct position for function attributes for functions
returning a pointer?

(I'm using gcc 4.3.2 for arm, OSELAS.Toolchain-1.99.3.6 here.  Could not
reproduce with Debian's gcc 4.4.5 for x86 using a minimal example.)

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |

RE: toplevel *again* out of sync

[Naveen H. S]

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="$noconfigdirs ${libgcj}"

The GCC commit should be modified as per the src commit.
Sorry, hunk of GCC was my mistake in the modified patch. 

>> Please fix the wrong side, and fix src/ChangeLog.  Thanks.

Sorry, I don't have the permissions to commit these changes. 

Thanks & Regards,
Naveen

Map tree to properties

[Hongtao]

 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

[RFC] Dealing with TARGET_CPU_CPP_BUILTINS

[FX]

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 proceed for the 
case of targets that employ a worker function (which thus does fully belong to, 
e.g., i386-c.c anymore).

I thank people who already commented on the issue, and would welcome comments 
and criticism of this patch. When the discussion seems to settle on whether 
this approach is agreeable, I will work on the TARGET_OS_CPP_BUILTINS macros 
and proceed to extensive testing, because this touches many targets (for now, 
it's only regtested on x86_64-linux).


As a response to earlier discussion: I did not move all this mechanism to being 
hooks-based because I don't have enough time to do so, and we need to move 
forward to fix this Fortran regression. Also, I believe my patch does not make 
it any harder to move to hooks in the future.


Thanks in advance for your help,
FX



cpu_cpp.ChangeLog
Description: Binary data


cpu_cpp.diff
Description: Binary data

Re: Map tree to properties

[Richard Guenther]

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
>

Re: Range-based for in c++98

[Rodrigo Rivas]

> 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 ':' or split it in two. Both options
are well beyond my intentions.
Anyway the C-style for loop does use tentative parsing, so you don't
avoid it completely.

>> 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 beginning a class body.  In the case of a type-specifier-seq, we do treat
> it as beginning a class body, but we give an error about it.

Well, the net effect is the same: the tentative parsing is aborted.
Then the C-style loop for parses the code, and it is this that prints
the error message if needed.

Regards.
Rodrigo

Re: Map tree to properties

[Basile Starynkevitch]

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 MELT is a plugin (or a branch). See 
http://gcc.gnu.org/wiki/MELT

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 mine, sont seulement les miennes} ***

Re: [C++-0x] User-defined literals.

[Jason Merrill]

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 that a user-defined 
literal is a single preprocessing token, so


1.2QQ

(one token) is different from

1.2 QQ

(two tokens).


Anyway, I managed to parse things like

  long double
  operator"" _foo(long double x) { return 2.0L * x; }

The result is a normal function that I can either call like
  operator "" _foo(1.2L);
or just
  _foo(1.2L);


You shouldn't be able to call it as just _foo(1.2L); an operator name is 
different from a normal function name.



1. A warning or error if a user chooses a suffix that gcc uses.  I was 
surprised that 'w', 'q', 'i', 'j' and several others were used by gcc for 
floats.  I won't be the only one.
The standard is clear that implementations get first crack at these but it 
shouldn't be a mystery or a surprise when things don't work as expected.


2. Should we at least pedwarn about user not starting a suffix with an underscore?  Probably.  Non-underscore suffixen are reserved to the implementation 
but I think a user should be able to use one if it's not used by gcc 
though the user risks non-portability and potential but unlikely future 
breakage.


Can you point me to the relevant wording?  I'm not finding it.


3. The big one: Getting the integer(long long) and float(long double) suffixes 
that are not used by gcc out of the preprocessor.  Then we can build the calls.


Yep, I think we want a new CPP token type for user-defined literals that 
encapsulates both the raw literal and the suffix.



4.  If, for long long and long double the usual signature is not found, first look 
for a: _suffix(char*) and failing that: template _suffix().  So we'll 
need to make the lookup of these two signatures more complex.


Right, this will need a new overload resolution function.  2.14.5 tells 
you how it works; look at the overload set, see if it contains a 
particular signature, and build up a normal call as appropriate.


Jason

Re: Range-based for in c++98

[Jason Merrill]

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 beginning a class body.  In the case of a type-specifier-seq, we do treat
it as beginning a class body, but we give an error about it.


Well, the net effect is the same: the tentative parsing is aborted.
Then the C-style loop for parses the code, and it is this that prints
the error message if needed.


True, it's just a question of what error you get from something like

for (struct A {} a : vector());

that is, is this parsed as a range-based for loop which invalidly 
defines a type, or as syntax nonsense?  Either way you get 
standard-conforming behavior, but the former gives a more useful diagnostic.


I think the right answer is, as you say, to split up 
cp_parser_simple_declaration so we can share the 
cp_parser_decl_specifier_seq call between the two cases.


Jason

Re: Range-based for in c++98

[Nicola Pero]

>> 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 ':' or split it in two. Both options
> are well beyond my intentions.

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 ;-)

What I've done for Objective-C fast enumeration (and what Apple did before me 
as well)
is implemented your idea of modifying the declaration parsing to accept ':' 
(well, 'in'
in the ObjC case) to terminate a declaration in that context:

 * when you start parsing the 'for', a flag is turned on in the parser that 
means that
we are "maybe in a fast enumeration"

 * then, you go on parsing your usual C for loop, but the code that parses 
expressions/declarations
has a special case for when it's "maybe in a fast enumeration", in which case 
it accepts
"in" as terminating the expression/declaration (as well as ";"), and moreover 
if it finds "in" in
there, it will save the declaration specially and make sure to communicate back 
to the for
parsing code that we are "really" in a fast enumeration

 * when the initial expression/declaration has been parsed, the for parsing 
code turns off the 
"maybe in a fast enumeration" flag; it now knows whether it's a normal for loop 
or a fast enumeration 
one and everything is easy from there on

It sounds like the same could apply to C++ range-based for-loops ?  Except you 
use ':' instead 
of 'in' ?  We could almost share the code - ie, set a single flag in the 
C++/ObjC++ parser to say we are
at the beginning of a 'for' loop, and have that flag turn on recognizing ':' 
(for range-based loops) 
and 'in' (only if (dialect_objc()), for fast ObjC++ enumeration) as terminating 
declarations.

The main disadvantage of doing things this way is making sure you won't 
misunderstand a ':' (or 'in')
as meaning a range-based for-loop (or fast enumeration loop) when it isn't.  
The best defense IMO is to
make sure ":" is only recognized in this way at the end of a declaration (where 
normally a ';' would be)
(this is harder in Objective-C, but should be easier in Objective-C++).

It's worth trying to think of valid cases where you'd use a ":" inside a C for 
loop though.

Anyway, let me know if this makes any sense or if I missed everything.  Am I 
right that the beginning
of a C++ range-based for-loop is identical to a standard C for loop up until 
the ':' ?  If not, obviously
this technique won't work. ;-)

Thanks

Re: [rfc] stack alignment macro cleanup

[Paul Brook]

> 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 function the stack pointer is only required to be 4-byte aligned.

We currently set S_B=64 and hope nothing notices that the prologue/epilogue 
involve transient 32-bit aligned values.

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.

Paul

Re: [rfc] stack alignment macro cleanup

[Richard Henderson]

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 hoping to document that it *is* a hardware property, and
remove some of the code that confuses it with an ABI property.
There's some of that even within the x86 backend, where the Win64
bits are wrong.


r~

Re: Re: [C++-0x] User-defined literals.

[3dw4rd]

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 of it 
>in the parser, which is incorrect; the draft says that a user-defined 
>literal is a single preprocessing token, so
>
>1.2QQ
>
>(one token) is different from
>
>1.2 QQ
>
>(two tokens).

Right.  I've resigned myself to having to scan for these as a single token.  
That (and Real Life) is what is slowing me down.
I think I may have to create new tree types for these literals.

>> Anyway, I managed to parse things like
>>
>>   long double
>>   operator"" _foo(long double x) { return 2.0L * x; }
>>
>> The result is a normal function that I can either call like
>>   operator "" _foo(1.2L);
>> or just
>>   _foo(1.2L);
>
>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-defined
  literals (2.14.8). However, except for the constraints described above, they 
are ordinary namespace-scope
  functions and function templates. In particular, they are looked up like 
ordinary functions and function tem-
  plates and they follow the same overload resolution rules. Also, they can be 
declared inline or constexpr,
  they may have internal or external linkage, they can be called explicitly, 
their addresses can be taken, etc.
  — end note ]

>> 1. A warning or error if a user chooses a suffix that gcc uses.  I was 
>surprised that 'w', 'q', 'i', 'j' and several others 
>were used by gcc for floats.  I won't be the only one.
>> The standard is clear that implementations get first crack at these but 
>it shouldn't be a mystery or a surprise when things don't work as expected.
>
>> 2. Should we at least pedwarn about user not starting a suffix with an 
>underscore?  Probably.  Non-underscore suffixen are reserved to the 
>implementation 
>
>but I think a user should be able to use one if it's not used by gcc 
>though the user risks non-portability and potential but unlikely future 
>breakage.
>
>Can you point me to the relevant wording?  I'm not finding it.

I *always* have trouble finding this ;-)

  17.6.3.3.5   User-defined literal suffixes   
   [usrlit.suffix]
  Literal suffix identifiers that do not start with an underscore are reserved for 
future standardization.

>> 3. The big one: Getting the integer(long long) and float(long double) 
>> suffixes 
>that are not used by gcc out of the preprocessor.  Then we can build the calls.
>
>Yep, I think we want a new CPP token type for user-defined literals that 
>encapsulates both the raw literal and the suffix.
>
>> 4.  If, for long long and long double the usual signature is not found, 
>first look for a: _suffix(char*) and failing that: template _suffix(). 
> So we'll need to make the lookup of these two signatures more complex.
>
>Right, this will need a new overload resolution function.  2.14.5 tells 
>you how it works; look at the overload set, see if it contains a 
>particular signature, and build up a normal call as appropriate.
>
>Jason
>

Thanks for looking this over.

Ed

Re: about function attributes for functions returning a pointer

[Ian Lance Taylor]

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 __section(S) __attribute__ ((__section__(#S)))
>   #define __cold __attribute__((__cold__))
>   #define notrace __attribute__((no_instrument_function))
>   #define __init  __section(.init.text) __cold notrace
>   #define __maybe_unused  __attribute__((unused))
>
> this still generated the "defined but unused" warning.
>
> Then after changing the definition to
>
>   static struct platform_device __init __maybe_unused 
> *imx_add_imx_dma(void)
>
> (i.e. move the * after the attribute stuff) the warning is gone.  In
> both cases (and when the function was used) it is put in the
> ".init.text" section though.  That is in the first case __init worked,
> but __maybe_unused did not.  Is this intended?  Do I something wrong?
> What is the most correct position for function attributes for functions
> returning a pointer?
>
> (I'm using gcc 4.3.2 for arm, OSELAS.Toolchain-1.99.3.6 here.  Could not
> reproduce with Debian's gcc 4.4.5 for x86 using a minimal example.)

This message is not appropriate for the mailing list g...@gcc.gnu.org.
It would be appropriate for gcc-h...@gcc.gnu.org.  Please take any
followups to gcc-help.  Thanks.

The syntax for attributes is documented at
http://gcc.gnu.org/onlinedocs/gcc-4.5.1/gcc/Attribute-Syntax.html .

I think the differences you are seeing are because some attributes can
apply to types and some can only apply to declarations.  Moving the
location of the __attribute__ affects which type it applies to.  In
particular __attribute__ ((unused)) may be used with a type, but
__attribute__ ((section (...))) may only be used with a declaration.

Ian

Re: [rfc] stack alignment macro cleanup

[Richard Henderson]

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.
> 
> It is used to implement -mstackreliagn. I think you should just
> move it to i386.c. Otherwise, you have to copy the same logic
> to where it is used in i386.c.

Well, the problem here is that there's stuff in i386.c related
to enforcing outgoing stack boundary that shouldn't be there.
It should be in the generic code where we manage the other bits
of the stack boundary code.

> On ia32,  INCOMING_STACK_BOUNDARY may be different
> from PREFERRED_STACK_BOUNDARY. It is used to support
> linking against libraries with 4byte incoming stack boundary and
> generate 16byte outgoing stack boundary.

As an aside let me say that I hate the word "preferred" in this
context.  It implies that the boundary is optional, and it's not.

Second, we're providing too many confusing options to our users.
While it's fine for LTO to manage all sorts of differing stack
alignment requirements for the functions its compiling, it's not
ok for us to expose all that complexity to the user.

There should only be the stack boundary as defined by the ABI,
plus the increased boundary discovered for local functions and
managed by cgraph.

I suspect that we have to keep the x86 backend command-line 
option that adjusts the ABI boundary for backward compatibility
with previous gcc versions.

> -mdrap is mainly for testing purpose and used in testsuite.
> It has caught many bugs. Removing it means regressions
> may become latent.

That simply means that the set of test cases is incomplete.
You get DRAP with highly aligned local variables plus alloca.
These same conditions ought to be testable with the code that
I'm adding for generic alignment of user variables, but do not
use a DRAP register.


r~

Re: Range-based for in c++98

[Rodrigo Rivas]

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 ;-)
Actually, they are already done. Just some minor improvements left :-)

The issue here is that I didn't feel comfortable modifying the
existing parser code of generic types just for the range-loop sake.

> Anyway, let me know if this makes any sense or if I missed everything.  Am I 
> right that the beginning
> of a C++ range-based for-loop is identical to a standard C for loop up until 
> the ':' ?  If not, obviously
> this technique won't work. ;-)
I don't know much about Obj-C, but I can tell that in C++ there are a
few subtle differences besides the obvious ':' vs. ';'.
C-loops may have an "expression" or a "simple-declaration" while
range-loops have a "type-specifier-seq" followed by a "declarator".
The case of an "expression" is not relevant to this discussion.

Putting it plainly, the differences are basically:
1. C-loops may declare several variables, while range-loops just one.
2. C-loops may specify a storage class (extern, static), while
range-loops may not.
3. C-loops may define new types, while range-loops may not.
4. C-loops may initialize the variables, while range-loops may not.

If these restrictions apply to the Obj-C fast-loops then the code
could be shared easily. If not, well, maybe with a little more work.

Regards.
Rodrigo

Re: [C++-0x] User-defined literals.

[Jason Merrill]

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-defined
   literals (2.14.8). However, except for the constraints described above, they 
are ordinary namespace-scope
   functions and function templates. In particular, they are looked up like 
ordinary functions and function tem-
   plates and they follow the same overload resolution rules. Also, they can be 
declared inline or constexpr,
   they may have internal or external linkage, they can be called explicitly, 
their addresses can be taken, etc.
   — end note ]


Yes, they are ordinary functions/function templates; ordinary functions 
with names like operator""x, which is different from plain x.



   17.6.3.3.5   User-defined literal suffixes  
[usrlit.suffix]
   Literal suffix identifiers that do not start with an underscore are reserved 
for future standardization.


Ah, thanks.

Jason

Re: [RFC] Dealing with TARGET_CPU_CPP_BUILTINS

[FX]

> 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 
> purpose).

Sure.

> I suppose calling cpp_define directly in target .c files (and generally 
> not having a separate set of preprocessor-using-front-end-hooks) is safe 
> in that all front ends are linked with cpplib, though I think the reason 
> they are so linked at present is just for the line-map code.

In the longer term, it sure makes sense to move all this to a more generic 
hooks-based mechanism.

FX

Re: [rfc] stack alignment macro cleanup

[Paul Brook]

> > 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 hardware property, and
> remove some of the code that confuses it with an ABI property.
> There's some of that even within the x86 backend, where the Win64
> bits are wrong.

So the 8-byte ABI requirement should be described by I_S_B?
Does/should/will this also DTRT for the outgoing stack pointer (combined with 
__builtin_alloca, etc)?

If so your proposal seems OK from an ARM backend perspective. The conversion 
may be nontrivial, but the end result sounds better.

In theory these values can be per-function, but I'm happy to ignore that.

Paul

Re: [rfc] stack alignment macro cleanup

[H.J. Lu]

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 differs from I_S_B due to proliferation of
>>>  command-line options.
>>
>> It is used to implement -mstackreliagn. I think you should just
>> move it to i386.c. Otherwise, you have to copy the same logic
>> to where it is used in i386.c.
>
> Well, the problem here is that there's stuff in i386.c related
> to enforcing outgoing stack boundary that shouldn't be there.
> It should be in the generic code where we manage the other bits
> of the stack boundary code.

Ia32 is a special case where the incoming/outgoing stack boundary
was changed from 4 byte to 16byte.  If you want to move that part
to generic, you need to define it for generic.

>> On ia32,  INCOMING_STACK_BOUNDARY may be different
>> from PREFERRED_STACK_BOUNDARY. It is used to support
>> linking against libraries with 4byte incoming stack boundary and
>> generate 16byte outgoing stack boundary.
>
> As an aside let me say that I hate the word "preferred" in this
> context.  It implies that the boundary is optional, and it's not.

Change it to OUTGOING_STACK_BOUNDARY.

> Second, we're providing too many confusing options to our users.
> While it's fine for LTO to manage all sorts of differing stack
> alignment requirements for the functions its compiling, it's not
> ok for us to expose all that complexity to the user.
>
> There should only be the stack boundary as defined by the ABI,
> plus the increased boundary discovered for local functions and
> managed by cgraph.
>
> I suspect that we have to keep the x86 backend command-line
> option that adjusts the ABI boundary for backward compatibility
> with previous gcc versions.

You need MIN_STACK_BOUNDARY, INCOMING_STACK_BOUNDARY
and PREFERRED_STACK_BOUNDARY to support those.

>> -mdrap is mainly for testing purpose and used in testsuite.
>> It has caught many bugs. Removing it means regressions
>> may become latent.
>
> That simply means that the set of test cases is incomplete.
> You get DRAP with highly aligned local variables plus alloca.
> These same conditions ought to be testable with the code that
> I'm adding for generic alignment of user variables, but do not
> use a DRAP register.
>

As I remembered, -mforce-drap exposed issues with register allocator.
ix86_force_drap is only referenced in one place in i386.c. I'd like to keep
it.  I don't see why it can't be moved to generic. It may expose problems
for other targets.

Thanks.


-- 
H.J.

Re: GCC Bugzilla upgrade to version 3.6.2 ready

[Florian Weimer]

* 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 violation of STD 11, it might
still cause problems in some applications.

Re: Problem in bootstrapping on mingw

[Ralf Wildenhues]

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 mode,
so the content really is identical, or diff should be used to compare
output

> > This test
> > in make is here a bit broken IMHO, as a content check would satisfy
> > needs for validity-check alone.

I'm not sure I understand.  There are three possibilities:
tm.texi is out of date wrt. tm.texi.in, or the user edited the wrong
file inadvertently, or things are in sync.

> I'm wondering about this part of the Makefile:
> 
> elif test $(srcdir)/doc/tm.texi -nt $(srcdir)/doc/tm.texi.in \
>   && test $(srcdir)/doc/tm.texi -nt $(srcdir)/doc/target.def; then \
> 
> because I don't think I have a $(srcdir)/doc/target.def, but 
> $(srcdir)/target.def

That looks like another bug to me.

I opened .
Might look into it, but not right now.

Cheers,
Ralf

Re: GCC Bugzilla upgrade to version 3.6.2 ready

[Frédéric Buclin]

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