__builtin_return_address for ARM

[Uwe Kleine-König]

Hello,

currently[1] __builtin_return_address for ARM only works with level == 0.

For ftrace in the linux kernel it would be great to implement that for
level > 0 (provided that framepointers or unwind information are
available of course).  On the linux-arm-kernel ML Mikael Pettersson[2]
said that "__builtin_return_address(N) where N>0 should never have been
introduced into gcc.".  Is that the general view for
__builtin_return_address or would a patch be accepted?

Up to now I only had a quick glance at gcc sources and after that I'm
not sure if I even find the place where to put an implementation, so any
help is welcome.

Best regards
Uwe

[1] at least in gcc 4.3.2 that I'm using.
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/52061/focus=52116
-- 
Pengutronix e.K.  | Uwe Kleine-König|
Industrial Linux Solutions| http://www.pengutronix.de/  |

Re: __builtin_return_address for ARM

[Paolo Bonzini]

Uwe Kleine-König wrote:
> Hello,
> 
> currently[1] __builtin_return_address for ARM only works with level == 0.
> 
> For ftrace in the linux kernel it would be great to implement that for
> level > 0 (provided that framepointers or unwind information are
> available of course).  On the linux-arm-kernel ML Mikael Pettersson[2]
> said that "__builtin_return_address(N) where N>0 should never have been
> introduced into gcc.".  Is that the general view for
> __builtin_return_address or would a patch be accepted?

My personal opinion is that Mikael Pettersson is right, but since the
damage is done why not extend it to more architectures.

I am not an ARM maintainer though.

Paolo

Re: __builtin_return_address for ARM

[Andrew Haley]

Uwe Kleine-König wrote:

> currently[1] __builtin_return_address for ARM only works with level == 0.
> 
> For ftrace in the linux kernel it would be great to implement that for
> level > 0 (provided that framepointers or unwind information are
> available of course).  On the linux-arm-kernel ML Mikael Pettersson[2]
> said that "__builtin_return_address(N) where N>0 should never have been
> introduced into gcc.".  Is that the general view for
> __builtin_return_address or would a patch be accepted?

The old APCS, if I recall correctly, required a frame pointer, so
__builtin_return_address(N) was easy.

> Up to now I only had a quick glance at gcc sources and after that I'm
> not sure if I even find the place where to put an implementation, so any
> help is welcome.

In userland ARM EABI doesn't have a frame pointer chain, so what you
suggest isn't possible.  However, we do need to unwind the stack so
we use the unwinder info.  For this you have to call  _Unwind_Backtrace
directly.

As I understand it, the ARM kernel can now do something similar.  So,
the only use for a __builtin_return_address(N) that used the frame
pointer chain would be if the code were compiled with nonstandard
options.

Andrew.

Re: __builtin_return_address for ARM

[Paul Brook]

On Wednesday 25 February 2009, Andrew Haley wrote:
> Uwe Kleine-König wrote:
> > currently[1] __builtin_return_address for ARM only works with level == 0.
> >
> > For ftrace in the linux kernel it would be great to implement that for
> > level > 0 (provided that framepointers or unwind information are
> > available of course).  On the linux-arm-kernel ML Mikael Pettersson[2]
> > said that "__builtin_return_address(N) where N>0 should never have been
> > introduced into gcc.".  Is that the general view for
> > __builtin_return_address or would a patch be accepted?
>
> The old APCS, if I recall correctly, required a frame pointer, so
> __builtin_return_address(N) was easy.

One minor exception: Thumb code generally doesn't have a frame pointer chain 
either, even on old-abi targets.

In general it's impossible to make __builtin_return_address(N) to work for 
N>0.

> > Up to now I only had a quick glance at gcc sources and after that I'm
> > not sure if I even find the place where to put an implementation, so any
> > help is welcome.
>
> In userland ARM EABI doesn't have a frame pointer chain, so what you
> suggest isn't possible.  However, we do need to unwind the stack so
> we use the unwinder info.  For this you have to call  _Unwind_Backtrace
> directly.
>
> As I understand it, the ARM kernel can now do something similar.  So,
> the only use for a __builtin_return_address(N) that used the frame
> pointer chain would be if the code were compiled with nonstandard
> options.

Correct.

The short story is that on modern ARM targets[1] there is no standard frame 
layout. It is not possible to do backtraces without using additional unwind 
tables. Current arm-linux kernels use a special set of options to allow this 
under most circumstances. However this often incurs a significant performance 
and code size hit, and isn't supported at all when you switch to Thumb mode.

Paul

[1] I believe the same is also true for some other targets, e.g. MIPS.

Re: Please block henry2000 from the wiki

[Gerald Pfeifer]

On Tue, 24 Feb 2009, Steven Bosscher wrote:
> Can someone *please* ban this nutcase from the wiki?
> There is almost weekly spam added to the wiki from this account.
> Thanks,

Let me forward this to the overseers team...

Gerald

Re: __builtin_return_address for ARM

[Richard Earnshaw]

On Wed, 2009-02-25 at 12:27 +, Paul Brook wrote:
> In general it's impossible to make __builtin_return_address(N) to work for 
> N>0.

In any situation where you need to look beyond the current frame needs
agreement as to how the data required can be found.  That's going to
have an impact somehow compared with not permitting such access (if a
compiler knows that its frame is private then it can make all kinds of
optimizations that would be unacceptable otherwise).  

There are essentially two ways of exposing the information needed here:

1) You can lay out every frame according to an agreed model
2) You can provide every frame with a description that can be
interpreted to recover the required information.

Neither is free.  Case 1 is the worst since it severely impacts
performance for code even if it never makes use of your feature.  Case 2
is less bad in performance terms, but has a major impact on space in
that the descriptions can be non-trivial.

IMO any solution based on case 1 is unacceptable -- why should I
penalise my code for some feature that you want, but I'm completely
uninterested in?  Case 2 is only acceptable if constructed in such a way
that the additional information can be automatically discarded if it is
not required -- again, why should I penalise my code size numbers for a
feature I don't want.

In statically linked images it might be possible to determine that the
additional unwind information is unneeded and simply throw it away
during linking, but you can't do that in a shared library environment,
so we're back to the original sticking point: who gave you the right to
impose such a levy on my code?

Finally, gcc for ARM conforms to the ABI for the ARM Architecture --
that says what can and can't be assumed when linking code built from
other tool chains.  If you want a feature like this to work you'll need
to persuade the other toolchain developers to co-operate -- I think they
are extremely unlikely to be interested

R.

real_format_for_mode / Porting GCC on a new arch

[Florent DEFAY]

Hi,

I would like to know more about REAL_MODE_FORMAT and real_format_for_mode.

I'm sorry because I already posted this email in gcc-help mailing-list
but there was no answer and maybe its right place is here ?

I am working on a port of GCC. The new xgcc generated crashes this way :

Program received signal SIGSEGV, Segmentation fault.
builtin_define_float_constants (name_prefix=0x83fcaf9 "FLT",
fp_suffix=0x8419523 "F", fp_cast=0x84109dd "%s", type=0xb7c0a410) at
../../gcc-4.3.3/gcc/c-cppbuiltin.c:108
108   gcc_assert (fmt->b != 10);

because fmt = 0.

This fmt results of
 fmt = REAL_MODE_FORMAT (TYPE_MODE (type));

and REAL_MODE_FORMAT is defined this way :

#define REAL_MODE_FORMAT(MODE)  \
 (real_format_for_mode[DECIMAL_FLOAT_MODE_P (MODE) \
   ? ((MODE - MIN_MODE_DECIMAL_FLOAT)  \
  + (MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1)) \
   : (MODE - MIN_MODE_FLOAT)])

But I did not find definition for real_format_for_mode, just an
"extern" in real.h (nothing in real.c) :

extern const struct real_format *
 real_format_for_mode[MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1
  + MAX_MODE_DECIMAL_FLOAT - MIN_MODE_DECIMAL_FLOAT + 1];


Should I include an implementation of real_format_for_mode in my
target.c ? If I should, how can I do that ? If not, how to avoid this
crash ? Any idea ?

Thank you.

Florent

Re: real_format_for_mode / Porting GCC on a new arch

[Richard Guenther]

On Wed, Feb 25, 2009 at 4:43 PM, Florent DEFAY
 wrote:
> Hi,
>
> I would like to know more about REAL_MODE_FORMAT and real_format_for_mode.
>
> I'm sorry because I already posted this email in gcc-help mailing-list
> but there was no answer and maybe its right place is here ?
>
> I am working on a port of GCC. The new xgcc generated crashes this way :
>
> Program received signal SIGSEGV, Segmentation fault.
> builtin_define_float_constants (name_prefix=0x83fcaf9 "FLT",
> fp_suffix=0x8419523 "F", fp_cast=0x84109dd "%s", type=0xb7c0a410) at
> ../../gcc-4.3.3/gcc/c-cppbuiltin.c:108
> 108       gcc_assert (fmt->b != 10);
>
> because fmt = 0.
>
> This fmt results of
>  fmt = REAL_MODE_FORMAT (TYPE_MODE (type));
>
> and REAL_MODE_FORMAT is defined this way :
>
> #define REAL_MODE_FORMAT(MODE)                                          \
>  (real_format_for_mode[DECIMAL_FLOAT_MODE_P (MODE)                     \
>                       ? ((MODE - MIN_MODE_DECIMAL_FLOAT)              \
>                          + (MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1))     \
>                       : (MODE - MIN_MODE_FLOAT)])
>
> But I did not find definition for real_format_for_mode, just an
> "extern" in real.h (nothing in real.c) :
>
> extern const struct real_format *
>  real_format_for_mode[MAX_MODE_FLOAT - MIN_MODE_FLOAT + 1
>                      + MAX_MODE_DECIMAL_FLOAT - MIN_MODE_DECIMAL_FLOAT + 1];
>
>
> Should I include an implementation of real_format_for_mode in my
> target.c ? If I should, how can I do that ? If not, how to avoid this
> crash ? Any idea ?

It is in the generated file insn-modes.c generated by genmodes.c
from machmode.def.

Richard.

> Thank you.
>
> Florent
>

query automaton

[Alex Turjan]

Hello,
Some time ago I asked a question regarding the possibility to schedule an 
operation on alternative functional units (FUs) AND depending on the chosen FUs 
to generate a dedicated assembly mnemonic. 

To give a simple example suppose I have a move operation that can be issued on 
one of the 2 different FUs:

(define_reservation "si_move""(q_salu, r_salu_rp,r_salu + r_salu_r_wp)
   |(q_smac, nothing,  r_smac + r_smac_wp) 
  ,nothing* 3") 

Depending on the occupied FUs one of the following assembly instructions are 
generated: move_salu or move_smac.
 
To find out which FUs were occupied I defined 2 query_cpu_unit-s:
(define_query_cpu_unit "q_salu"  "aut1")
(define_query_cpu_unit "q_smac"  "aut1")

,which further on (during the sched2 hook TARGET_SCHED_DFA_NEW_CYCLE) are used 
to find out which of the 2 alternative reservations the automaton has taken. 
Based on this decision I add some information within the insn rtx which later 
on is used to dump "move_salu" or "move_smac".

This approach was successful as long as the units claimed by "si_move" belong 
to one and the same automaton ( i.e., q_salu, q_smac, r_salu_rp, r_salu, 
r_salu_r_wp, r_smac, r_smac_wp belong to "aut1").

If I try to split "aut1" into (lets say 2) automatons I get generated incorrect 
code (i.e., the choice of choosing the proper unit is not correct anymore.) 

QUESTION: Is there such constraint that the units part of the alternatives of a 
reservation must belong to the same automaton?


  

Re: [Ada] Wrong code in gcc/ada/a-teioed.adb causing FAIL of ACATS ?cxf3a01 on mipsel and ia64

[Laurent GUERBY]

On Wed, 2009-02-18 at 10:23 +0100, Laurent GUERBY wrote:
> On Wed, 2009-02-18 at 08:56 +0100, Arnaud Charlet wrote:
> > > > OK for stage 1 (GCC 4.5), currently pretty much everything is frozen on
> > > > mainline, except regressions (I hope stage 1 will open soon, since we 
> > > > have
> > > > monthes of backlog of various fixes and new development blocked right 
> > > > now
> > > > which will be painful to merge).
> > > 
> > > If the ACATS test fails on ia64-linux, that's a regression from 4.3.x.
> > 
> > OK, that's a little surprising, but if it's indeed a confirmed
> > regression, then it's fine to commit now.
> 
> I didn't put a regression tag because I don't have access to ia64-linux
> but according to Andreas Schwab testresults ACATS was clean on ia64 4.3:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg01606.html
> 
> And was failing all cxf3a0N tests back in november:
> 
> http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg01831.html
> 
> Currently they do not fail on ia64 4.4 but I guess any unrelated commit 
> can make them fail again. Also formally this bug has security
> implications since we're overwritting memory, so may be I should
> backport it.
> 
> Let me know if you think it's still okay for 4.4 and
> if it's okay for 4.3 backport commit (after testing there of course).

After checking cxf3a01 showed up here:

http://gcc.gnu.org/ml/gcc-testresults/2009-01/msg02370.html

So I went ahead and commited the buffer overflow fix on 4.4.
If it shows up on 4.3 too I'll backport.

Laurent

Re: __builtin_return_address for ARM

[Dave Korn]

Paul Brook wrote:
> On Wednesday 25 February 2009, Andrew Haley wrote:

> In general it's impossible to make __builtin_return_address(N) to work for
>  N>0.

>> In userland ARM EABI doesn't have a frame pointer chain, so what you 
>> suggest isn't possible.  However, we do need to unwind the stack so we
>> use the unwinder info.  For this you have to call  _Unwind_Backtrace 
>> directly.
>> 
>> As I understand it, the ARM kernel can now do something similar.  So, the
>> only use for a __builtin_return_address(N) that used the frame pointer
>> chain would be if the code were compiled with nonstandard options.
> 
> Correct.

  Well, but wouldn't it still be nice if __builtin_return_address(N) was
implemented for N>0 by libcalling into the unwinder for you?  Obviously this
would still have to return NULL at runtime when you're running on a DW2 target
without any EH frame data present in memory (and I guess it wouldn't work on
SjLj targets either), but wouldn't it still be a nice convenience feature for
users?

cheers,
  DaveK

Is a Better Warning for this Stupid Mistake?

[Joel Sherrill]

Hi,

I made a stupid typo and accidentally included
an unprotected file from itself.  The error
message generated by gcc surprised me and I
wondered if there was a better alternative.

$ cat recursive_include.c
#include "recursive_include.c"
$ gcc -c recursive_include.c 


from recursive_include.c:1:
recursive_include.c:1:31: error: #include nested too deeply
$ gcc -c recursive_include.c 2>&1 | wc -l
200

Thanks.

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

Fwd: Constant folding and Constant propagation

[Jean Christophe Beyler]

Dear all,

I was working on the machine description so I was postponing a bit
this problem but now I have a bit more time on my hands to handle it.
I'm starting to look at the various links and code you've provided me
and will keep you posted if I make any headway or not ;-).

> For the GCC port I work on, I have fixed this by weighing the rtx_cost
> of propagating a register copy Vs propagating the constant into an insn.
> I have an initial patch for this problem.

Do you have a link to that patch? So that I can see if it applies for me ?

Thanks,
Jc


On Tue, Feb 10, 2009 at 2:25 PM, Rahul Kharche  wrote:
> I am looking at a related problem in GCSE, GCC 4.3 whereby constants
> are propagated to their use irrespective of the final instruction cost
> of generating them (machine cycles or instruction count).
>
> Global constant propagation effectively voids common expressions that
> form large constants, identified by global CSE. This is especially
> true of SYMBOl_REF constants like section-anchors generated while
> indexing global arrays.
>
> For the GCC port I work on, I have fixed this by weighing the rtx_cost
> of propagating a register copy Vs propagating the constant into an insn.
> I have an initial patch for this problem.
>
>
> Rahul Vijay Kharche
>

gcc-4.2-20090225 is now available

[gccadmin]

Snapshot gcc-4.2-20090225 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090225/
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/gcc-4_2-branch 
revision 144437

You'll find:

gcc-4.2-20090225.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20090225.tar.bz2 C front end and core compiler

gcc-ada-4.2-20090225.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20090225.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20090225.tar.bz2  C++ front end and runtime

gcc-java-4.2-20090225.tar.bz2 Java front end and runtime

gcc-objc-4.2-20090225.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20090225.tar.bz2The GCC testsuite

Diffs from 4.2-20090218 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Fwd: Pseudo-templates

[Patrick Moran]

Dear all,

    We are two students in a Compiler Design course who have been
assigned to work on a gcc beginners project. We have chosen the
project on making pseudo-templated containers, and we had some
questions about the semantics you want from them.  The gcc page
specifically mentioned splay trees and hash tables, so we will ask
about those.

    The goal of the project was stated to be the elimination of
abstraction penalties.  The hash table and splay tree both store
entries by pointer (except that splay tree can cast ints to the
pointer and back out).  Would you prefer a generic container that held
items by value? We could do this, but it would break code that expects
aliases to be preserved.

 We are currently working under the assumption that it is
acceptable for all of our function-like macros to take the type of the
stored elements.  Do you agree? Is it okay for lookup function macros
to take the type they are looking up? If we can take the type, we can
make the semantics of returning pointers much more elegant.

Thanks for your help,
Patrick Moran
Walter Maguire

Announce: MPFR 2.4.1 is released

[Vincent Lefevre]

After a buffer overflow has been found (and fixed) in the
mpfr_snprintf and mpfr_vsnprintf functions of MPFR 2.4.0,
it has been decided to release MPFR 2.4.1 immediately.
It is available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-2.4.1/

The MD5's:
22402995cf2496d8faea42c8da02ce1f  mpfr-2.4.1.tar.lzma
c5ee0a8ce82ad55fe29ac57edd35d09e  mpfr-2.4.1.tar.bz2
a70bbde2a23d82e8f3314d4293500ae4  mpfr-2.4.1.tar.gz
63c1ebc19f720853c75e5bef22405490  mpfr-2.4.1.zip

Changes from version 2.4.0 to version 2.4.1:
- Security fix in mpfr_snprintf and mpfr_vsnprintf (buffer overflow).
- Configure: new checks for length modifiers hh and ll (new in C99)
  as hh is absent on alpha-OSF1-V5.
- Miscellaneous corrections in the MPFR manual. In particular,
  mpfr_inits, mpfr_inits2, mpfr_clears and MPFR_DECL_INIT have been
  in the public API since MPFR 2.4.0.

You can send success and failure reports to , and give
us the canonical system name as returned by the config.guess script,
the processor and compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 2.4.1 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Is a Better Warning for this Stupid Mistake?

[James Dennett]

On Wed, Feb 25, 2009 at 9:56 AM, Joel Sherrill
 wrote:
> Hi,
>
> I made a stupid typo and accidentally included
> an unprotected file from itself.  The error
> message generated by gcc surprised me and I
> wondered if there was a better alternative.
>
> $ cat recursive_include.c
> #include "recursive_include.c"
> $ gcc -c recursive_include.c 
>                from recursive_include.c:1:
> recursive_include.c:1:31: error: #include nested too deeply
> $ gcc -c recursive_include.c 2>&1 | wc -l
> 200
>
> Thanks.

That seems like a pretty good error message to me!  We could apepnd "
(possibly recursive #include?)" or similar, but I don't know that
would help.  Recursive #include (suitably terminated, of course) is an
unusual but not unheard of implementation technique.

-- James

Re: Fwd: Pseudo-templates

[Ian Lance Taylor]

Patrick Moran  writes:

>     We are two students in a Compiler Design course who have been
> assigned to work on a gcc beginners project. We have chosen the
> project on making pseudo-templated containers, and we had some
> questions about the semantics you want from them.  The gcc page
> specifically mentioned splay trees and hash tables, so we will ask
> about those.
>
>     The goal of the project was stated to be the elimination of
> abstraction penalties.  The hash table and splay tree both store
> entries by pointer (except that splay tree can cast ints to the
> pointer and back out).  Would you prefer a generic container that held
> items by value? We could do this, but it would break code that expects
> aliases to be preserved.
>
>  We are currently working under the assumption that it is
> acceptable for all of our function-like macros to take the type of the
> stored elements.  Do you agree? Is it okay for lookup function macros
> to take the type they are looking up? If we can take the type, we can
> make the semantics of returning pointers much more elegant.

Thanks for your interest.

I personally have been slowing working on the gcc-in-cxx branch which
will support writing gcc in C++.  I think that if that approach is
accepted, then pseudo-template code will become much less
interesting--we can just use C++ template code instead.  So from my
perspective this may be a less interesting project today.

That said, there is an existing example of a pseudo-template container,
in gcc/vec.h.  Any new pseudo-template should be similar to that one.

New hash table code should store objects by value, as you suggest.  I
don't think there would be much gain to having another way to write a
hash table which stores pointers.  You are correct that this could be
only used in certain cases.

It would be worth first identifying places where performance critical
code avoids the general code.  One example might be the identifier hash
table in libcpp/symtab.c.  Why do we use a special purpose hash table
there rather than using htab_t?

Ian