Re: diagnostics-branch merged into mainline

[NightStrike]

On Fri, Jun 12, 2009 at 9:49 PM, Aldy Hernandez wrote:
> On Sat, Jun 13, 2009 at 01:51:42AM +0100, Dave Korn wrote:
>> Aldy Hernandez wrote:
>> > Hi folks.
>> >
>> > At the last minute Ian got a patch in that touched a bunch of places
>> > that I was also changing.  I resolved the conflicts, and bootstrapped
>> > and tested for C and C++.  Unfortunately, people kept committing stuff
>> > that caused conflicts, so I broke down and committed after a minor C/C++
>> > bootstrap.
>>
>>   Did you tell anyone that you were merging a branch to mainline?  I honestly
>> didn't see an announcement.  (Is there any reason why you shouldn't have
>> requested a freeze?)
>
> The branch was approved by a GWP, I didn't know you needed to make a
> special announcement.
>
> I will be fixing any regressions shortly.
>

Your committal of r148442 has caused an ICE during the build of libgcc
for targetting win64:

../../../gcc/libgcc/../gcc/libgcc2.c:2054:1: warning: no previous
prototype for ‘getpagesize’
../../../gcc/libgcc/../gcc/libgcc2.c:2064:1: warning: no previous
prototype for ‘mprotect’
../../../gcc/libgcc/../gcc/libgcc2.c:1:0: internal compiler error:
Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_divdi3.o] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2

Re: tree.c compiler warning

[Andreas Krebbel]

On Sun, Jun 14, 2009 at 11:02:04PM +0200, Giuseppe Scrivano wrote:
> Hello,
> 
> last GCC revision has a compiler warning at line 8502.  Is this
> extremely trivial patch OK?

This has already been fixed:
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01109.html

Sorry for the breakage.

Bye,

-Andreas-

Pointer analysis in GCC-4.3.0 - Getting spurious pointsTo pair.

[Seema Ravandale]

Hi.

Gimple code of the program I have tried to get the pointsTo
information is as follow:

 A = 0;
 B = &A;
 C = &B;
 D = &C;
 D.1255 = *D;
 D = (int * * *) D.1255;

The expected pointsTo pairs  are,
B = { A } , A = { },  C = { B }, D.1255 = { B }, D = { B  C }

But with GCC-4.3.0, and command line options  -fdump-ipa-all
-funit-at-a-time  -fipa-pta, we are getting spurious pointsTo pairs
as,
D.1255 = { B A } , D = { B C A }

Is the current analysis Flow-insensitive? Even if It is, the sperious
information, D -> A should not occur.
Please, Can someone clarify on this?

- Seema

Re: Pointer analysis in GCC-4.3.0 - Getting spurious pointsTo pair.

[Richard Guenther]

On Mon, Jun 15, 2009 at 12:33 PM, Seema Ravandale wrote:
> Hi.
>
> Gimple code of the program I have tried to get the pointsTo
> information is as follow:
>
>  A = 0;
>  B = &A;
>  C = &B;
>  D = &C;
>  D.1255 = *D;
>  D = (int * * *) D.1255;
>
> The expected pointsTo pairs  are,
> B = { A } , A = { },  C = { B }, D.1255 = { B }, D = { B  C }
>
> But with GCC-4.3.0, and command line options  -fdump-ipa-all
> -funit-at-a-time  -fipa-pta, we are getting spurious pointsTo pairs
> as,
> D.1255 = { B A } , D = { B C A }
>
> Is the current analysis Flow-insensitive? Even if It is, the sperious
> information, D -> A should not occur.
> Please, Can someone clarify on this?

IPA-PTA is completely bogus (and its results are unused).  Further
GCC 4.3 has a very large number of known oddities with computing
points-to information, GCC 4.4 is a lot better here but only GCC 4.5
has fixes for all (known) bugs.

Richard.

> - Seema
>

Re: Address mode offset spill

[Alexandre Oliva]

On Jun 14, 2009, daniel tian  wrote:

> Now, for immediate movement, it is achieved to move large immediate.
> But I don't know how to make the address mode legitimate. Now I try to
> add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
> cc1 still crashed, when the frame size is larger than 255. Do I miss
> something?

One common source of this kind of error is prologue/epilogue expanders.
Since they run after reload, they must emit valid instructions to
save/restore registers and to adjust the stack and frame pointers.

-- 
Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist  Red Hat Brazil Compiler Engineer

Re: plugin callbacks after compiler errors

[Rafael Espindola]

> As I said, it's a minor polish issue. It may be sufficient to just have a
> note in the documentation as Basil suggested.

I would prefer just changing the documentation too. In general I think
that plugins
should see gcc the same way a builtin pass does. If a plugin needs to
look at the
IL early in the pipeline it should be ready to work with previous errors.

>
> Taras
>


Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: plugin callbacks after compiler errors

[Diego Novillo]

On Mon, Jun 15, 2009 at 09:32, Rafael Espindola wrote:
>> As I said, it's a minor polish issue. It may be sufficient to just have a
>> note in the documentation as Basil suggested.
>
> I would prefer just changing the documentation too. In general I think
> that plugins
> should see gcc the same way a builtin pass does. If a plugin needs to
> look at the
> IL early in the pipeline it should be ready to work with previous errors.

Agreed.  As we chatted last week, we may want to offer a simplified
interface to those plugins that are never going to be integrated with
the compiler.  For now, plugins should get on the same roller coaster
the rest of the passes are in.

However, that may be more work than it's worth.  It would force an API
translation layer that may be burdensome to maintain.  I would prefer
to wait until we have more experience with plugin usage.


Diego.

Re: mainline breakage (r148442)

[Aldy Hernandez]

oliver.kell...@t-online.de (Oliver Kellogg) writes:

> Anybody else seeing this?
>
> ‘lower_try_finally_switch’:
> ../../../SOURCES/gcc/gcc/tree-eh.c:1350:5: error: ‘tf_loc’ may be used
> uninitialized in this function

Funny, this was never picked up in any of my bootstraps, but it is
indeed a bug.

This is an obvious fix I will be committing as soon as tests are done.

* tree-eh.c (lower_try_finally_switch): Initialize tf_loc.

Index: tree-eh.c
===
--- tree-eh.c   (revision 148490)
+++ tree-eh.c   (working copy)
@@ -1333,7 +1333,7 @@ lower_try_finally_switch (struct leh_sta
   gimple_seq finally;
   struct pointer_map_t *cont_map = NULL;
   /* The location of the TRY_FINALLY stmt.  */
-  location_t tf_loc;
+  location_t tf_loc = gimple_location (tf->try_finally_expr);
   /* The location of the finally block.  */
   location_t finally_loc;
 

Re: diagnostics-branch merged into mainline

[Aldy Hernandez]

> Your committal of r148442 has caused an ICE during the build of libgcc
> for targetting win64:

I have this pending patch, which may or may not fix this.

http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01113.html

Can you try and see if it fixes it?  Otherwise, can you find out where
the compiler is dying so I can fix this.

Aldy

Re: git mirror at gcc.gnu.org

[Rafael Espindola]

> Mine are.  I ignore all heads in gcc.git, and just map its remotes into my
> remotes by manually specifying remote.origin.fetch.  Not very pretty, but it
> seems to produce the optimal result.  See my stuff in the lower section of
> http://gcc.gnu.org/wiki/GitMirror for more details.

It fails with

$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'
$ git fetch
fatal: refs/remotes/origin/gcc-4_0-branch tracks both
refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch

> Jason
>

Cheers,
-- 
Rafael Avila de Espindola

Google | Gordon House | Barrow Street | Dublin 4 | Ireland
Registered in Dublin, Ireland | Registration Number: 368047

Re: plugin callbacks after compiler errors

[Basile STARYNKEVITCH]

Rafael Espindola wrote:

As I said, it's a minor polish issue. It may be sufficient to just have a
note in the documentation as Basil suggested.


I am sorry to be picky, but my first name is spelled Basile (in France, 
where I live and am a citizen).
I do know that is it written Basil in English & Vasilii in 
(transliterated) Russian; but I prefer to be called by my official first 
name; unless it is an English or American habit to change the spelling 
of names.


Indeed my parents me after Basil of Caesarea, 
http://en.wikipedia.org/wiki/Basil_of_Caesarea (called Basil the Great 
in the Orthodox church; he is the author of several remarkable texts, 
and of the http://en.wikipedia.org/wiki/Basil_of_Caesarea).


But please do me a favor: on mailing lists spell my first name as it is 
in my signature. Actually, I would suppose that rule is nearly universal!


Of course, I don't care if russian speakers call me Vassilii or even Vassia.

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: git mirror at gcc.gnu.org

[Jason Merrill]

On 06/15/2009 10:28 AM, Rafael Espindola wrote:

It fails with

$ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'


That's not my section; my contribution starts at

Alternative git-svn procedure (Jason Merrill)

Jason

Re: diagnostics-branch merged into mainline

[NightStrike]

On Mon, Jun 15, 2009 at 9:52 AM, Aldy Hernandez wrote:
>> Your committal of r148442 has caused an ICE during the build of libgcc
>> for targetting win64:
>
> I have this pending patch, which may or may not fix this.
>
> http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01113.html
>
> Can you try and see if it fixes it?  Otherwise, can you find out where
> the compiler is dying so I can fix this.
>
> Aldy
>

I tried applying your patch to HEAD, but it looks like it already is.
So, using r148494, we now don't get to the libgcc part even:

../../gcc/gcc/config/i386/winnt.c: In function ‘i386_pe_encode_section_info’:
../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
function ‘make_decl_one_only’
make[1]: *** [winnt.o] Error 1
make: *** [all-gcc] Error 2

[GSoC] [plugins] [ici] function cloning + fine-grain optimizations/program instrumentation

[Grigori Fursin]

Hi Yuanjie, Liang, et al,

This email is about further GSoC'09 developments for plugins, generic function 
cloning, fine-grain optimizations
and program instrumentation this summer. Considering that the basic 
infrastructure is now available I would like
to agree on further developments based on the feedback I got during last 3 
weeks so that we could extend 
the projects quickly. Though this email primarily concerns Yuanjie and Liang, I 
am sending this email to all the colleagues involved in the project or who has 
been interested at some point as well as GCC and cTuning mailing lists just to 
make everyone aware of the developments. This is a long email so if you are not 
interested in these projects, please skip it ... 

1) Originally we thought to use stable GCC 4.4.0 with plugin/ICI support for 
GSoC (already prepared), 
however considering that GCC 4.5 will have plugin support and extended function 
cloning capabilities, 
we should eventually move all the developments to the trunk. Zbigniew mentioned 
that he will synchronize 
ICI with  the current trunk fully within 2 weeks, so we can start working on 
GCC 4.4.0 (with plugins and ICI)
until then (plugins shouldn't change much but some gluing with new GCC will be 
required) and then sync 
with GCC 4.5 + synced ICI.

2) We need to prepare a plugin that uses XML library (libxml2 for example - 
http://xmlsoft.org) 
and records basic information about compilation flow. I suggest that we record
the following info per function for now (we can use filename 
gcc_compilation_flow..xml for example):
* GCC version
* Plugin version which has been used to record info
* File name
* function name
** Within inter-procedural stage, we can call a function name #IP#
and besides IP passes also provide some global info such as which optimization 
flags/parameters has been used
* function start line (source) and end line and other currently available ICI 
features from http://ctuning.org/wiki/index.php/CTools:ICI:List_of_features
* function specific optimizations or code generation flags (if applicable - I 
think
Mike Meissner's patch that enables function-specific flags has been included in 
GCC 4.5)
* passes
** available fine-grain optimization within passes 

Except fine-grain optimizations, all the information should be already 
available 
and there are 2 ICI plugin (test1, test2) that show how to get this info...

We should record this info per function to avoid large files for large projects 
since often 
we may want to control only a few functions. This can help with memory and cpu 
utilization
when using libxml ...

We should be able to control which functions to process using either a command 
line argument
with a list of functions or an environment variable (which we can later convert 
into command
line argument). If it's empty, all the functions are processed.

3) When we want to perform function cloning or use fine-grain 
optimization/instrumentation,
we can use the same XML files created during the record stage (or prepare them 
manually/automatically
using external tools) and add additional fields.
We will need to perform function cloning using a new IP pass (as described in 
the GCC Summit
presentation by Honza Hubicka). 

We can provide info about which functions to clone in XML file for a IP cloning 
pass,
i.e. something like:
generic_cloning
 libadapt, other libraries if needed such as 
hardware counters monitoring
(if needed)
foo
  2
  _clone
  gcc_adapt (this function will be called before the clone 
and will select which
clone to use based on either machine description or monitoring of hardware 
counters or dataset features
to enable online dynamic optimization for statically compiled programs, etc)
 boo
  3   
  _clone
  

Basically, when we create clones, we need to make the following substitution 
for a code:

foo{
/* before cloning */
...
}

foo{
/* after cloning */

switch (gcc_adapt(function_number)) {
case 1: foo_clone1(..); break;
case 2: foo_clone2(..); break;
default:
/* original code */
...
}

Basically, when the generic_cloning pass is invoked, it will be communicating 
with
a plugin asking for all the necessary information to clone 1 function. The 
plugin
will send an "End" instruction when all the functions are processed so that 
compilation
could continue ...

We need to decide how to number functions (so that the selection is fast) 
and how to aggregate this info is we compile projects with multiple functions.
Also, we can have a mode when we skip the function number in case we adapt
for different architecture and compile clones with different -msse2, -msse3 
flags ...

After cloning is done, all the cloned functions should appear in recorded XML 
file.
We can then optimize those clones using different flags or different passes
or changing fine-grain optimizations. 

We can use OProfile or gprof to monitor performance however we may also need 
instrumentation
capabilities to add calls to external time/hardware counters monitoring rout

Re: Build report for AIX 6.1

[David Edelsohn]

Mario,

I, personally, have not encountered MAXDATA limits building
application with GCC (as opposed to Java), but I can see that some
large applications might encounter them.  I bootstrap GCC every night
and build many GNU applications with the default GCC configuration.
I can adjust the default GCC bootstrap to include a larger MAXDATA
value.

Is there a particular reason that you use different values on AIX 5.3
and AIX 6.1:  MAXDATA=0x4000 on AIX 5.3 and MAXDATA=0x5000 on
AIX 6.1?

Thanks, David

On Thu, Apr 23, 2009 at 1:26 PM, Mario Linke wrote:
> Hi,
>
> i just built  GCC 4.4.0  on AIX 6.1 using the following commands:
>        setenv LDR_CNTRL MAXDATA=0x5000
>        ../gcc-4.4.0/configure --disable-multilib --with-gmp=/usr/local
>        make bootstrap-lean
>        make install
>
> $ config.guess
> powerpc-ibm-aix6.1.0.0
>
> $ gcc -v
> Using built-in specs.
> Target: powerpc-ibm-aix6.1.0.0
> Configured with: ../gcc-4.4.0/configure --disable-multilib
> --with-gmp=/usr/local
> Thread model: aix
> gcc version 4.4.0 (GCC)
> The system is an IBM System p JS21 Blade with AIX 6.1 at the latest
> patchlevel.
> The building c-complier is  IBM xlC 10.1
> Make is  gnu-make 3.80
>
> The disable-multilib configure-option shouldn't be necessary, i used it
> for buildtime- and space-saving reasons.
> The 'setenv LDR_CNTRL MAXDATA=0x5000' was necessary to get gcc built
> (found that hint in the gcc bug database).
> Generally the AIX default memory settings are too low to build/install
> the actual gcc-versions. Had to increase the max-data-segment size for
> the building user and the environment size on the system, too...
>
>
> Mario Linke
>
>
>
>

Re: git mirror at gcc.gnu.org

[Bernie Innocenti]

On 06/15/09 16:28, Rafael Espindola wrote:
>> Mine are.  I ignore all heads in gcc.git, and just map its remotes into my
>> remotes by manually specifying remote.origin.fetch.  Not very pretty, but it
>> seems to produce the optimal result.  See my stuff in the lower section of
>> http://gcc.gnu.org/wiki/GitMirror for more details.
> 
> It fails with
> 
> $ git config --add remote.origin.fetch '+refs/remotes/*:refs/remotes/origin/*'
> $ git fetch
> fatal: refs/remotes/origin/gcc-4_0-branch tracks both
> refs/remotes/gcc-4_0-branch and refs/heads/gcc-4_0-branch

Perhaps I should remove those "friendly" refs pointing at the remote
branches?  Or can we find a better alternative?  Their use was to make a
few frequently used branches readily visible in gitweb and with a simple
clone.

Perhaps git-svn could be configured to map svn branches directly to the
local namespace instead of remotes/ ?

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

Re: i370 port

[Ulrich Weigand]

Paul Edwards wrote:

> One of the things that I experienced when porting 3.2.3 to MVS
> was that GCC was sensitive to the exact floating point representation.
> 
> Register selection was different depending on those slight differences.
> 
> Below is what documentation I have for it.  Dave Edwards, who
> wrote another S/370 emulator, was the one who discovered that.
> 
> Does anyone know if that was changed somewhere along the line?
> 
> BFN.  Paul.
> 
> 
> 
> 17. The assembler code generated by gccmvs when run on the
> PC is slightly different (even when the same parameters
> are used for code generation) from that when run on the
> mainframe, if -O2 is used instead of -Os. But functionally
> equivalent. This non-deterministic nature of the compiler
> is disconcerting. It seems to not always allocate registers
> consistently. This has been traced to floating point code
> in predict.c and local-alloc.c which is sensitive to the
> very small changes in floating point representation. This
> should be changed to include deltas when comparing floating
> point values. Here's an example of what's happening:

I agree that GCC output should not depend on details of the host
floating point representation.  (Ideally, the output of GCC built
as a cross-compiler should not depend on the host architecture
at all.)

However, it is hard to say whether such observations made on a
GCC 3.2 code base have any relevance to the current code -- for
example, local-alloc.c does not even exist any more, we now have
a completely new register allocator.

I'd recommend you go ahead with a port to current mainline and
verify whether you still see problems along those lines; if so,
it would be appropriate to open a bug report against GCC.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: Address mode offset spill

[Ian Lance Taylor]

daniel tian  writes:

> There is a problem I encountered. I port gcc to 32bit RISC. The
> LOAD/STORE only has 8bit displacement. If the immediate displacement
> larger than 256, the displacement must be force into register. In
> addition, if the immediate is larger than 512, it can only move into
> one specified register R0.
>
> Like:
>
> LW  R2  (R1)  #252 ;;  means R2 = Mem(R1 + 255)
>
> LW R2  (R1)  #508;;   it is wrong. immediate 508 should force into
> register first.
>
>
> LW R2  (R1)  #0x500;; it is wrong, immediate 0x500 should force into
> register R0 first.
>
> Now, for immediate movement, it is achieved to move large immediate.
> But I don't know how to make the address mode legitimate. Now I try to
> add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
> cc1 still crashed, when the frame size is larger than 255. Do I miss
> something?

I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
debug that.

Ian

Re: diagnostics-branch merged into mainline

[Aldy Hernandez]

> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?:
> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
> function ?make_decl_one_only?

make_decl_one_only expects one argument, and that's what's being fed.
Could you please debug this and find out what's going on?

Re: diagnostics-branch merged into mainline

[NightStrike]

On Mon, Jun 15, 2009 at 2:05 PM, Aldy Hernandez wrote:
>> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?:
>> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
>> function ?make_decl_one_only?
>
> make_decl_one_only expects one argument, and that's what's being fed.
> Could you please debug this and find out what's going on?
>

I don't really know how to.  Hopefully, Kai can help (I have him on the CC list)

Re: Speed regression (m68k)

[Ian Lance Taylor]

ami_stuff  writes:

> I notice about 20% speed regression with GCC 4.4.0 PNGCrush build compared to 
> GCC 3.4.0 build (Amiga 68...@50mhz). 
>
> CFLAGS = -I. -DNO_FSEEKO -O2 -fomit-frame-pointer -Wall -m68060 -s
>
> Here are the results:
>
> GCC 3.4.0:
>
> CPU time used = 267.340 seconds (decoding 16.940,
> encoding 247.800, other 2.600 seconds)
>
> GCC 4.4.0:
>
> CPU time used = 328.360 seconds (decoding 16.800,
> encoding 309.260, other 2.300 seconds) 
>
> Maybe someone with m68k Debian/PPC/x86 can compile PNGCrush with GCC 3.4.0 
> and GCC 4.4.0, so we will know if this regression happens there too?

I assume that you are measuring the speed of the compiled code, not the
speed of the compiler itself.  Can you open a bug report about this,
with enough information for other people to reproduce the results (e.g.,
pointer to source code being compiled and input file(s)).  Thanks.

Ian

Re: [gnat] reuse of ASTs already constructed

[Oliver Kellogg]

A further problem that I'm seeing is that
Lib.Writ.Write_Unit_Information assumes the current unit to depend on
all entries in Lib.Units. However, when letting Lib.Units accumulate
units across several compilations this dependency does not
necessarily hold true. The generated ALI files for compilation 2
to N contain more entries than needed.

--Oliver


On Sat, 2009-05-09 at 16:08 -0400, Robert Dewar wrote:
> Oliver Kellogg wrote:
> > On 2009-05-04, at 07:36 +0200, Oliver Kellogg wrote:
> >> Robert Dewar wrote:
> >>> How about not doing the name expansion in-place but rather
> >>> storing the expanded name in an extra node field?
> >>> You could have a separate vector for expanded names I suppose ...
> >> So be it. I will change the code to not overwrite the Name field
> >> with the expanded name but rather store the expanded name in a
> >> data structure separate from the Node.
> >>
> > 
> > Luckily, this change was limited to the Exp_Dbug package body.
> > FYI I am appending the diff.
> > The new Q_E_Name array holds the Name_Id for the expanded name
> > of a given entity. The implementation as a fixed array is
> > preliminary and I would appreciate suggestions on a better
> > data structure to use.
> 
> use a table .. we never use fixed length arrays in the compiler

Re: Address mode offset spill

[Jeff Law]

Ian Lance Taylor wrote:

daniel tian  writes:

  

There is a problem I encountered. I port gcc to 32bit RISC. The
LOAD/STORE only has 8bit displacement. If the immediate displacement
larger than 256, the displacement must be force into register. In
addition, if the immediate is larger than 512, it can only move into
one specified register R0.

Like:

LW  R2  (R1)  #252 ;;  means R2 = Mem(R1 + 255)

LW R2  (R1)  #508;;   it is wrong. immediate 508 should force into
register first.


LW R2  (R1)  #0x500;; it is wrong, immediate 0x500 should force into
register R0 first.

Now, for immediate movement, it is achieved to move large immediate.
But I don't know how to make the address mode legitimate. Now I try to
add the code in LEGITIMIZE_RELOAD_ADDRESS like sh.md, or arm.md. But
cc1 still crashed, when the frame size is larger than 255. Do I miss
something?



I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
debug that.
  
LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this -- 
LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific approaches 
for reloading can generate more efficient code than the generic code in 
reload.   The generic code should be producing correct, though 
potentially inefficient code.


I do agree that the target is going to need secondary reload support.

jeff

Re: Address mode offset spill

[Ian Lance Taylor]

Jeff Law  writes:

>> I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
>> TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
>> debug that.
>>   
> LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this -- 
> LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific
> approaches for reloading can generate more efficient code than the
> generic code in reload.   The generic code should be producing
> correct, though potentially inefficient code.

I will just note that this is a long-standing point of disagreement
between Jeff and me.

Ian

Re: Address mode offset spill

[Jeff Law]

Ian Lance Taylor wrote:

Jeff Law  writes:

  

I would fix this in LEGITIMIZE_RELOAD_ADDRESS or in
TARGET_SECONDARY_RELOAD.  I don't know why cc1 crashed, you will have to
debug that.
  
  
LEGITIMIZE_RELOAD_ADDRESS is not the right place to handle this -- 
LEGITIMIZE_RELOAD_ADDRESS is to be used when target specific

approaches for reloading can generate more efficient code than the
generic code in reload.   The generic code should be producing
correct, though potentially inefficient code.



I will just note that this is a long-standing point of disagreement
between Jeff and me.
  
True.  But in this specific case we're talking about an out of range 
offset that requires a specific register for the secondary reload.  
That's a case reload should already be handling correctly.

Ian
  

C++0x unrestricted unions

[Rodolfo Lima]

Hi, I'd like to know if somebody is implementing c++0x's unrestricted
unions (N2544) in g++, or if there are any plans to do it in mid-term.

Thanks,
Rodolfo Lima

Re: C++0x unrestricted unions

[Rodolfo Lima]

Rodolfo Lima escreveu:
> Hi, I'd like to know if somebody is implementing c++0x's unrestricted
> unions (N2544) in g++, or if there are any plans to do it in mid-term.

Sorry, by 'in mid-term' I meant "in a not too distant timeframe".

[]s,
rod

Re: Speed regression (m68k)

[ami_stuff]

Hi,

> I assume that you are measuring the speed of the compiled code, not the
> speed of the compiler itself.

Yes.

> Can you open a bug report about this,
> with enough information for other people to reproduce the results (e.g.,
> pointer to source code being compiled and input file(s)).

Done. Bug #40454.

Regards

uint64_t alignof odditity on x86

[Jan Engelhardt]

Hi,


I noticed that __alignof__(uint64_t) will return 8, while
__alignof__(struct { uint64_t x; }) will give only 4. This
run on a typical 32-bit x86 CPU (GCC config below).

What I am wondering about is why GCC was coded to give different
alignments here. If aligning a single uint64_t to a boundary of 8 for
whatever reason there may be (performance?), not doing so when it is
inside a struct appears to be a discrepancy.


---
Using built-in specs.
Target: i586-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info 
--mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib 
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada 
--enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 
--enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ 
--with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap 
--with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit 
--enable-libstdcxx-allocator=new --disable-libstdcxx-pch 
--enable-version-specific-runtime-libs --program-suffix=-4.3 
--enable-linux-futex --without-system-libunwind --with-cpu=generic 
--build=i586-suse-linux
Thread model: posix
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)
openSUSE 11.1 i586.