headers
namhyung | 1 Oct 2008 04:45
Picon
Gravatar

gccint documentation suggestion

Hi,

At first, I'm not sure it is right place to discussing this.
If not, please kindly let me know where the right place is.

On section 10.7 Constant Expression Types, 
4th, 5th, 6th and 7th paragraphs of "const_vector" description seem to be
misplaced. 
They seem to be applied to "CONST_DOUBLE_MEM/CHAIN", "CONST_DOUBLE_LOW"
and "CONST0/1/2_RTX", respectively (they have own  <at> findexs in
gcc/doc/rtl.texi).
So, I think it is better to separate as new items.

On section 10.13 Conversions,
"(fix:m x)" item appears twice, so it looks like a typo (at least for me).
If not (and there is no reason really to do so),
it is better to merge them into a single item.

TIA

p.s. Please cc me, I'm not subscribed :-)

--

-- 
Regards,
Namhyung Kim
Permalink | Reply | 2 comments |
headers
Vladimir Sterjantov | 1 Oct 2008 09:34
Picon
Favicon

What to do with hardware exception (unaligned access) ? ARM920T processor

Hi!

Processor ARM920T, chip Atmel at91rm9200.

Simple C code:

char c[30];
unsigned short *pN = &c[1];

*pN = 0x1234;

causes hardware exeption - memory aborts (used to implement memory 
protection or virtual memory).

We have a lot of source code, with pieces of code like this, which must 
be ported from x86 to ARM9.

Are there any compiler options to handle this exception?

I compile it by using arm-elf-gcc 4.3.2 under Linux.
binutils-2.18.

Thanks.

Best regrads,
Vladimir
Permalink | Reply | 7 comments |
headers
Martin Guy | 1 Oct 2008 10:21
Picon
Favicon

Re: What to do with hardware exception (unaligned access) ? ARM920T processor

On 10/1/08, Vladimir Sterjantov <vfs <at> tersy.ru> wrote:
>  Processor ARM920T, chip Atmel at91rm9200.
>
>  char c[30];
>  unsigned short *pN = &c[1];
>
>  *pN = 0x1234;

Accesses to shorts on ARM need to be aligned to an even address, and
longs to a 4-byte address. Otherwise the access returns (eg, for a
4-byte word pointer) is *(p & ~3) >>> *(p & 3) (where >>> is byte
rotate, not bit shift). Or causes a memory fault, if that's how your
system is configured.

If you don't want to make the code portable and your are running a
recent Linux, a fast fix is to
  echo 2 > /proc/cpu/alignment
which should make the kernel trap misaligned accesses and fix them up
for you, with a loss in performance of course. The real answer is to
fix the code...

    M
Permalink | Reply | 1 comment |
headers
Grigori Fursin | 1 Oct 2008 10:35
Picon
Picon
Favicon

RE: Defining a common plugin machinery

Dear all,

I noticed a long discussion about plugins for GCC. 
It seems that it's currently moving toward important legal issues,
however, I wanted to backtrack and just mention that we
at INRIA and in the MILEPOST project are clearly interested
in having a proper plugin system in the mainline of GCC which 
will simplify our work on automatically tuning optimization heuristics
(cost models, etc) or easily adding new transformations
and modules for program analysis.

We currently have a simple plugin system within Interactive Compilation 
Interface (http://gcc-ici.sourceforge.net) that can load external DLL plugin 
(transparently through the environment variables to avoid changing project 
Makefiles or through command line), substitutes the original Pass Manager 
to be able to call any passes (new analysis passes for example) in any legal order
and has an event mechanism to rise events in any place in GCC and 
pass data to the plugin (such as information about cost model
dependencies) or return parameters (such as decisions about transformations
for example). 

Since it's relatively simple, we are currently able to port it to the new versions
of GCC without problems, however, naturally, we would like to have
this functionality within the GCC mainline with the defined API (that
what I discussed with Taras from Mozilla during GCC Summit this year).
I believe it may help making GCC a modular compiler and simplify future
designs (and can be in line with the idea to use C++ for GCC development
if Ian moves this project forward). By the way, Hugh Leather 
also developed an interesting plugin system for GCC that allows 
to substitute internal GCC functions with the external ones within
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marco Manfredini | 1 Oct 2008 13:15
Picon

Re: What to do with hardware exception (unaligned access) ? ARM920T processor

On Wednesday 01 October 2008, Martin Guy wrote:
> If you don't want to make the code portable and your are running a
> recent Linux, a fast fix is to
>   echo 2 > /proc/cpu/alignment
> which should make the kernel trap misaligned accesses and fix them up
> for you, with a loss in performance of course. The real answer is to
> fix the code...

...and this is where -Wcast-align should help. The OP should also have a look 
at -Wpadded and -Wpacked, because this may expose similar pitfalls.

This writeup looks like a good start for the OP:
http://lecs.cs.ucla.edu/wiki/index.php/XScale_alignment
Permalink | Reply | 0 comments |
headers
Sergei Poselenov | 1 Oct 2008 13:20

Re: GCC 4.2.2 arm-linux-gnueabi: c++ exceptions handling?

Hello all,

I've found the cause of my problem - it's binutils 2.17.50.
Using ld 2.18, or even 2.17.90 creates workable libstdc++.so.

Regards,
Sergei

Sergei Poselenov wrote:
> Hello all,
> 
> I've built the above cross-compiler and ran the GCC testsuite.
> Noted a lot of c++ tests failed with the same output:
> ...
> terminate called after throwing an instance of 'int'
> terminate called recursively
> Aborted
> ...
> 
> Compiler details:
> Reading specs from 
> /opt/eldk-4.2-arm-2008-09-24/usr/bin/../lib/gcc/arm-linux-gnueabi/4.2.2/specs 
> 
> Target: arm-linux-gnueabi
> Configured with: 
>
/work/psl/eldk-builds/arm-2008-09-24/work/usr/src/denx/BUILD/crosstool-0.43/build/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi/gcc-4.2.2/configure 
> --target=arm-linux-gnueabi --host=i686-host_pc-linux-gnu 
>
--prefix=/var/tmp/eldk.Jb5047/usr/crosstool/gcc-4.2.2-glibc-20070515T2025-eldk/arm-linux-gnueabi
(Continue reading)

Permalink | Reply | 0 comments |
headers
Hugh Leather | 1 Oct 2008 15:18
Picon
Favicon

Re: Defining a common plugin machinery

Sorry, I think this bounced twice.

Hugh Leather wrote:
> Hi All,
>
>     Thanks, Grigori, for mentioning my plugin system, libplugin, which 
> can be found at http://libplugin.sourceforge.net/.
>
>     I have been meaning to release it but finding the time to finish 
> off the documentation and upload all the newest code to SourceForge 
> has been difficult (both code and docs on SourceForge are some months 
> out of date).
>
>     The plugin system was built to support MilePost goals for GCC, as 
> we need to be able to capture events during compilation as well as 
> change compilation behaviour.  Here are some of the features of the 
> system:
>
> *Application agnostic.*
>     The plugin system is not GCC specific but can be used to make any 
> application plugin aware.  Plugin management is handled through a 
> shared library which GCC, or any other application, can link to. 
>
>     I think if GCC took a similar approach then it would benefit from 
> the exposure the system received elsewhere and the wider community 
> would also have access to a professionally built plugin system.  As 
> the plugin system becomes more powerful, GCC reaps the rewards without 
> having to change a line of code.
>
>     The other, huge advantage of this, together with the design I'll
(Continue reading)

Permalink | Reply | 38 comments |
headers
Ramana Radhakrishnan | 1 Oct 2008 15:22
Picon

query regarding adding a pass to undo final value replacement.

Hi ,

Based on the conversation in the thread at
http://gcc.gnu.org/ml/gcc/2008-03/msg00513.html , we've tried to get a
pass trying to undo final value replacement going. The initial
implementation was done by Pranav Bhandarkar when he was employed at
Azingo as part of work sponsored by Icera Semiconductor.  I've been
trying to get this working with my private port over here.  We intend
to contribute this back once our copyright assignments are sorted and
if this will be acceptable to all. I've been getting a few compile
time ICEs with this approach and haven't been able to resolve them
well enough yet. Whilst doing so, I wanted to check on the approach as
outlined below and ask if there's anything that we might have missed
or any problem that one can see with us going along these lines.
Thanks for your time and patience.

cheers
Ramana

1) Understanding what scalar evolution does.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Consider the following pseudo code.

function memcpy (src_pointer, dst_pointer)
src_1 = src_pointer;
dst_1 = dst_pointer;
L1:
*dst_1 = *src_1  (Word copy)
dst++;
(Continue reading)

Permalink | Reply | 16 comments |
headers
Richard Guenther | 1 Oct 2008 15:59
Picon

Re: query regarding adding a pass to undo final value replacement.

On Wed, Oct 1, 2008 at 3:22 PM, Ramana Radhakrishnan <ramana.r <at> gmail.com> wrote:
> Hi ,
>
> Based on the conversation in the thread at
> http://gcc.gnu.org/ml/gcc/2008-03/msg00513.html , we've tried to get a
> pass trying to undo final value replacement going. The initial
> implementation was done by Pranav Bhandarkar when he was employed at
> Azingo as part of work sponsored by Icera Semiconductor.  I've been
> trying to get this working with my private port over here.  We intend
> to contribute this back once our copyright assignments are sorted and
> if this will be acceptable to all. I've been getting a few compile
> time ICEs with this approach and haven't been able to resolve them
> well enough yet. Whilst doing so, I wanted to check on the approach as
> outlined below and ask if there's anything that we might have missed
> or any problem that one can see with us going along these lines.
> Thanks for your time and patience.

Some quick comments.  First, do you have a non-pseudo-code testcase
that exposes the extra computations?  Second, I think rather than
trying to undo what SCEV const(!)-prop is doing adjust its cost
model (maybe there isn't one) to not create the costly substitutions.

Thanks,
Richard.

> cheers
> Ramana
>
>
>
(Continue reading)

Permalink | Reply | 5 comments |
headers
Vladimir Makarov | 1 Oct 2008 16:12
Picon
Favicon

Re: IRA accumulated costs

Hi, Richard.  Returning to accurate cost accumulation issue you found 
recently.  Here is the patch fixing it.  You could try, if you want, how 
MIPS  will behave with it.  The patch also more accurately calculates 
ALLOCNO_CALL_FREQ which affects decision to spill allocno in 
assign_hard_reg if it is more profitable.

2008-10-01  Vladimir Makarov  <vmakarov <at> redhat.com>

    * ira-int.h (ira_allocno): Add member updated_cover_class_cost.
    (ALLOCNO_UPDATED_COVER_CLASS_COST): New.
    (ira_fast_allocation): Remove the prototype.

    * ira-color.c (update_copy_costs, allocno_cost_compare_func,
    assign_hard_reg, calculate_allocno_spill_cost): Use updated costs.
    (color_pass): Modify the updated costs.
    (ira_color): Rename to color.  Make it static.
    (ira_fast_allocation): Rename to fast_allocation.  Make it static.
    (ira_color): New function.

    * ira-conflicts.c (process_regs_for_copy): Propagate hard reg cost
    change.

    * ira-lives.c (last_call_num, allocno_saved_at_call): New
    variables.
    (set_allocno_live, clear_allocno_live, mark_ref_live,
    mark_ref_dead): Invalidate corresponding element of
    allocno_saved_at_call.
    (process_bb_node_lives): Increment last_call_num.  Setup
    allocno_saved_at_call.  Don't increase ALLOCNO_CALL_FREQ if the
    allocno was already saved.
(Continue reading)

Permalink | Reply | 5 comments |

Gmane