announce: MELT plugin 0.8rc2 for 4.6

[Basile Starynkevitch]

Hello All,

It is my pleasure to announce the 2nd release candidate of MELT plugin
version 0.8 for GCC 4.6

You can download it from http://gcc-melt.org/
gnuzipped tar http://gcc-melt.org/melt-0.8rc2-plugin-for-gcc-4.6.tgz
of md5sum 880db34a1d76a27f51ba4d594e725519


###
NEWS for 0.8rc2 MELT plugin for gcc-4.6

July 08th, 2011: Release candidate 2 of melt-0.8rc1-plugin-for-gcc-4.6

New features:
 * support for pragmas for MELT

 * the MELT garbage collector is called less often, using the
   PLUGIN_GGC_START hook.

 * several new c-iterators and c-matchers.

 * added static analyzing pass gccframe, useful for melt-runtime.c

 * reject nested defun-s, you should use letrec or let...

 * the MELT plugin build-melt-plugin.sh has changed incompatibly
   (w.r.t. the previous 0.7 MELT plugin release).

 * debug_msg, assert_msg ... should work, thanks to MELT_HAVE_DEBUG
   preprocessor flag, even when melt.so is a plugin for a GCC without
   checks enabled.

 * melt-runtime.h has a melt_gcc_version integer variable and
   melt-runtime.c should be given MELT_GCC_VERSION preprocessor
   constant.

* runfile mode compiles quickly (with debug_msg support). Add new mode
  translatequickly to compile quickly (with debug_msg & assert_msg
  support).

Many bugfixes
  (but some bugs remain)



Thanks to Pierre Vittet and to Alexandre Lissy for their contributions.

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: Cross compiler build instructions - PowerPC

[Rohit Arul Raj]

On Wed, Mar 23, 2011 at 5:55 PM, Joseph S. Myers
 wrote:
> On Wed, 23 Mar 2011, Rohit Arul Raj wrote:
>
>> Hello All,
>>
>> I have been trying to build a cross compiler (for PowerPC) on x86_64
>> linux host. I followed the build procedure given in the link below:
>>
>> http://www.eglibc.org/archives/patches/msg00078.html
>
> You should be referring to the current checked-in version of this
> documentation, not a four-year-old draft.  However, it doesn't appear to
> have relevant changes.  Maxim, perhaps we should add
> --disable-decimal-float --disable-libffi --disable-libquadmath to the
> configure options for the first GCC in EGLIBC.cross-building?
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Any updates on this one yet?
Adding "--disable-decimal-float --disable-libffi
--disable-libquadmath" to configure options gives the same error.

Regards,
Rohit

Re: announce: MELT plugin 0.8rc2 for 4.6

[Allan McRae]

On 08/07/11 18:06, Basile Starynkevitch wrote:


Hello All,

It is my pleasure to announce the 2nd release candidate of MELT plugin
version 0.8 for GCC 4.6

You can download it from http://gcc-melt.org/
gnuzipped tar http://gcc-melt.org/melt-0.8rc2-plugin-for-gcc-4.6.tgz
of md5sum 880db34a1d76a27f51ba4d594e725519



I get an ICE after stage zero:

build-melt-plugin: Did MELT stage zero successfully
build-melt-plugin: Starting MELT first stage
build-melt-plugin: making MELT using 
/home/allan/Desktop/melt-0.8rc2-plugin-for-gcc-4.6/melt-build.mk warmelt1
make: Entering directory 
`/home/allan/Desktop/melt-0.8rc2-plugin-for-gcc-4.6'

if [ -d melt-stage1 ]; then true; else mkdir melt-stage1; fi
cd melt-stage0-dynamic/ ; rm -f warmelt-first-0.so; ln -s 
warmelt-first-0.d.so warmelt-first-0.so
cd melt-stage0-dynamic/ ; rm -f warmelt-base-0.so; ln -s 
warmelt-base-0.d.so warmelt-base-0.so
cd melt-stage0-dynamic/ ; rm -f warmelt-debug-0.so; ln -s 
warmelt-debug-0.d.so warmelt-debug-0.so
cd melt-stage0-dynamic/ ; rm -f warmelt-macro-0.so; ln -s 
warmelt-macro-0.d.so warmelt-macro-0.so
cd melt-stage0-dynamic/ ; rm -f warmelt-normal-0.so; ln -s 
warmelt-normal-0.d.so warmelt-normal-0.so
cd melt-stage0-dynamic/ ; rm -f warmelt-normatch-0.so; ln -s 
warmelt-normatch-0.d.so warmelt-normatch-0.so
cd melt-stage0-dynamic/ ; rm -f warmelt-genobj-0.so; ln -s 
warmelt-genobj-0.d.so warmelt-genobj-0.so
cd melt-stage0-dynamic/ ; rm -f warmelt-outobj-0.so; ln -s 
warmelt-outobj-0.d.so warmelt-outobj-0.so
gcc -fplugin=./melt.so -c -o /dev/null  -Wno-shadow 
-fplugin-arg-melt-mode=translateinit 
-fplugin-arg-melt-module-makefile=/home/allan/Desktop/melt-0.8rc2-plugin-for-gcc-4.6/melt-module.mk 
-fplugin-arg-melt-module-make-command=/usr/bin/make 
-fplugin-arg-melt-tempdir=. -fplugin-arg-melt-bootstrapping 
-fplugin-arg-melt-init=\

warmelt-first-0:\
warmelt-base-0:\
warmelt-debug-0:\
warmelt-macro-0:\
warmelt-normal-0:\
warmelt-normatch-0:\
warmelt-genobj-0:\
warmelt-outobj-0 \

-fplugin-arg-melt-arg=/home/allan/Desktop/melt-0.8rc2-plugin-for-gcc-4.6/melt/warmelt-first.melt 
 -frandom-seed=c763ca1e2b1d2b340ebd439b \

  -fplugin-arg-melt-module-path=melt-stage1:melt-stage0-dynamic:.:. \

-fplugin-arg-melt-source-path=melt-stage1:melt-stage0-dynamic:.:/home/allan/Desktop/melt-0.8rc2-plugin-for-gcc-4.6/melt:/home/allan/Desktop/melt-0.8rc2-plugin-for-gcc-4.6/melt/generated:/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/melt-source 
\
  -fplugin-arg-melt-output=melt-stage1/warmelt-first-1.c 
empty-file-for-melt.c
cc1: note: MELT is bootstrapping so ignore builtin source directory 
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/melt-source and module 
directory /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/libexec/melt-modules
*** WARNING *** there are active plugins, do not report this as a bug 
unless you can reproduce it without enabling any plugins.

Event| Plugins
PLUGIN_FINISH_UNIT   | melt
PLUGIN_FINISH| melt
PLUGIN_GGC_START | melt
PLUGIN_GGC_MARKING   | melt
PLUGIN_ATTRIBUTES| melt
PLUGIN_START_UNIT| melt
PLUGIN_PRAGMAS   | melt
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make: *** [melt-stage1/warmelt-first-1.c] Error 1
make: Leaving directory `/home/allan/Desktop/melt-0.8rc2-plugin-for-gcc-4.6'
build-melt-plugin error: doing melt make warmelt1 failed


> gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: /build/src/gcc-4.6.1/configure --prefix=/usr 
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man 
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ 
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared 
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-clocale=gnu 
--enable-gnu-unique-object --enable-linker-build-id --with-ppl 
--enable-cloog-backend=isl --enable-lto --enable-gold 
--enable-ld=default --enable-plugin --with-plugin-ld=ld.gold 
--disable-multilib --disable-libstdcxx-pch --enable-checking=release

Thread model: posix
gcc version 4.6.1 (GCC)


What further information do you require for this?

Allan

Re: Cross compiler build instructions - PowerPC

[Andreas Schwab]

Rohit Arul Raj  writes:

> Any updates on this one yet?
> Adding "--disable-decimal-float --disable-libffi
> --disable-libquadmath" to configure options gives the same error.

It is much easier to bootstrap with some previous glibc build (any one
will do) already in sysroot.

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: announce: MELT plugin 0.8rc2 for 4.6

[Basile Starynkevitch]

On Fri, Jul 08, 2011 at 06:41:30PM +1000, Allan McRae wrote:
> empty-file-for-melt.c
> cc1: note: MELT is bootstrapping so ignore builtin source directory
> /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/melt-source and module
> directory
> /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/libexec/melt-modules
> *** WARNING *** there are active plugins, do not report this as a
> bug unless you can reproduce it without enabling any plugins.
> Event| Plugins
> PLUGIN_FINISH_UNIT   | melt
> PLUGIN_FINISH| melt
> PLUGIN_GGC_START | melt
> PLUGIN_GGC_MARKING   | melt
> PLUGIN_ATTRIBUTES| melt
> PLUGIN_START_UNIT| melt
> PLUGIN_PRAGMAS   | melt
> cc1: internal compiler error: Segmentation fault
> Please submit a full bug report,


Did you install a previous release of MELT plugin (e.g. 0.8rc1 or 0.7)? If
you did, you have to remove it entirely (eg remove all files named *melt*)?

> 
> What further information do you require for this?

Perhaps a gdb backtrace of the crash?

Thanks for the bug report. I will try to reproduce it!

Cheers

-- 
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: announce: MELT plugin 0.8rc2 for 4.6

[Allan McRae]

On 08/07/11 19:15, Basile Starynkevitch wrote:

On Fri, Jul 08, 2011 at 06:41:30PM +1000, Allan McRae wrote:

empty-file-for-melt.c
cc1: note: MELT is bootstrapping so ignore builtin source directory
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/melt-source and module
directory
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/libexec/melt-modules
*** WARNING *** there are active plugins, do not report this as a
bug unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | melt
PLUGIN_FINISH| melt
PLUGIN_GGC_START | melt
PLUGIN_GGC_MARKING   | melt
PLUGIN_ATTRIBUTES| melt
PLUGIN_START_UNIT| melt
PLUGIN_PRAGMAS   | melt
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,



Did you install a previous release of MELT plugin (e.g. 0.8rc1 or 0.7)? If
you did, you have to remove it entirely (eg remove all files named *melt*)?



I have no previous MELT plugins installed.



What further information do you require for this?


Perhaps a gdb backtrace of the crash?



Maybe not that helpful given things have been stripped...  I can rebuild 
without stripping if helpful.


#0  0xf7fe6941 in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#1  0xf788ed60 in ?? () from /lib/libc.so.6
#2  0xf788f1e7 in _dl_sym () from /lib/libc.so.6
#3  0xf7902d66 in ?? () from /lib/libdl.so.2
#4  0xf7feb66f in _dl_catch_error () from /lib/ld-linux.so.2
#5  0xf790333a in ?? () from /lib/libdl.so.2
#6  0xf7902de4 in dlsym () from /lib/libdl.so.2
#7  0xf71a7605 in melt_dlsym_all () from ./melt.so
#8  0xf71a7666 in melt_dynobjstruct_fieldoffset_at () from ./melt.so
#9  0xf708ad3c in warmelt_first_initialmeltchunk_19 ()
   from melt-stage0-dynamic/warmelt-first-0.so
#10 0xf70fa485 in start_module_melt ()
   from melt-stage0-dynamic/warmelt-first-0.so
#11 0xf71b9b3b in meltgc_make_load_melt_module () from ./melt.so
#12 0xf71c3bc3 in plugin_init () from ./melt.so
#13 0x082d5565 in ?? ()
#14 0x087663c5 in htab_traverse_noresize ()
#15 0x082d5ebd in initialize_plugins ()
#16 0x08364c2e in toplev_main ()
#17 0x080d645b in main ()


Note that this only happens for me on i686.  I have just set off a build 
on my x86_64 system (toolchain build with exactly the same 
configuration) and I do not run into this issue.


Allan

Re: announce: MELT plugin 0.8rc2 for 4.6

[Pierre Vittet]

I got a bug if we use mawk instead of gawk however it is not the bug of 
Allan, as it just end the script early (before starting compiling).



I have also been able to compile the current branch with a 32 bits 
system (I can't compile the plugin because my 32 bits system has no gcc 
4.6).


So it looks to appear only on 32 bits when compiling the plugin.


Pierre Vittet

[C]: Unnecessary int(16)->long(32) promotion: Bug in C front end?

[Georg-Johann Lay]

Hi,

I am on 4.7 trunk (175991)

Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
--prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
--enable-languages=c,c++ --with-dwarf2 --disable-lto

Suppose the following source from gcc.c-torture/compile/pr30338.c:

extern char *grub_scratch_mem;
int testload_func (char *arg, int flags)
{
  int i;
  for (i = 0; i < 0x10ac0; i++)
if (*((unsigned char *) ((0x20 + i + (int) grub_scratch_mem)))
!= *((unsigned char *) ((0x30 + i + (int) grub_scratch_mem
  return 0;
  return 1;
}

And compiled with the command line

> avr-gcc pr30338.c -S -Os -dp -mmcu=atmega128 -fdump-tree-original

pr30338.c: In function 'testload_func':
pr30338.c:9:11: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]
pr30338.c:10:14: warning: cast to pointer from integer of different
size [-Wint-to-pointer-cast]

Frist of all, the warning is incorrect because Pmode=HImode=int on AVR.

Second, the dump reads:
{
  int i;

int i;
  i = 0;
  :;
  if (*(unsigned char *) (int) (((long int) i + 2097152) + (long int)
(int) grub_scratch_mem) != *(unsigned char *) (int) (((long int) i +
3145728) + (long int) (int) grub_scratch_mem))
{
  return 0;
}
  i++ ;
  goto ;
  return 1;
}

Why is there a (long int) at all? There is nothing in the source that
mentions long or L or UL suffix on a constant.  That is: all constants
can be truncated mod 2**16.

However, I observe the long throughout all passes, e.g. SImode and
finally in extendhisi2 insn that do all computation in SImode instead
of HImode.

Is this a bug in the C front end?

BTW: With -x c++ all the function collapses to while(1);

Johann

gcc 4.6.1 expand is playing tricks on me

[Paulo J. Matos]

Hi,

I got a few size regressions when moving from 4.5.3 to 4.6.1, all due to 
the same issue.


I have code that is basically a double word memory move:
void simple1(uint32 *a, uint32 *b) { *a = *b; }

GCC 4.6.1 is from this gimple:
simple1 (uint32 * a, uint32 * b)
{
  uint32 D.1927;

  # BLOCK 2 freq:1
  # PRED: ENTRY [100.0%]  (fallthru,exec)
  D.1927_2 = *b_1(D);
  *a_3(D) = D.1927_2;
  return;
  # SUCC: EXIT [100.0%]

}

calling gen_movhi twice with:
call1 :
operand[0]: (reg:HI 19 [ D.1927 ])
operand[1]: (mem:HI (reg/v/f:QI 21 [ b ]))

call2 :
operand[0]: (mem:HI (reg/v/f:QI 20 [ a ]))
operand[1]: (reg:HI 19 [ D.1927 ])

while GCC 4.5.3 for _exactly_ the same gimple (as far as it is shown in 
the logs) it only calls gen_movhi with:

operand[0]: (mem:HI (reg/v/f:QI 20 [ a ]))
operand[1]: (mem:HI (reg/v/f:QI 21 [ b ]))

This seems to boil down to code that looks exactly the same between 
4.5.3-4.6.1 in cfgexpand.c, expand_gimple_basic_block:

  def_operand_p def_p;
  def_p = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_DEF);

  if (def_p != NULL)
{
  /* Ignore this stmt if it is in the list of
 replaceable expressions.  */
  if (SA.values
  && bitmap_bit_p (SA.values,
   SSA_NAME_VERSION (DEF_FROM_PTR (def_p
continue;
}
  last = expand_gimple_stmt (stmt);
  maybe_dump_rtl_for_gimple_stmt (stmt, last);


gcc4.5.3 hits continue the first time it gets there and gcc4.6.1 fails 
the inner if and enters expand_gimple_stmt twice.


From the comment in ssaexpand.h for the definition of SA.values, it says:
  /* For an SSA name version V bit V is set iff TER decided that 



 its definition should be forwarded.  */
  bitmap values;

What is TER? Any hints on why GCC 4.6.1 has now a different behaviour to 
GCC 4.5.3?


Cheers,
--
Paulo Matos

Re: [C]: Unnecessary int(16)->long(32) promotion: Bug in C front end?

[Jakub Jelinek]

On Fri, Jul 08, 2011 at 02:36:23PM +0200, Georg-Johann Lay wrote:
> I am on 4.7 trunk (175991)
> 
> Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
> --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
> --enable-languages=c,c++ --with-dwarf2 --disable-lto
> 
> Suppose the following source from gcc.c-torture/compile/pr30338.c:
> 
> extern char *grub_scratch_mem;
> int testload_func (char *arg, int flags)
> {
>   int i;
>   for (i = 0; i < 0x10ac0; i++)
> if (*((unsigned char *) ((0x20 + i + (int) grub_scratch_mem)))
> != *((unsigned char *) ((0x30 + i + (int) grub_scratch_mem
>   return 0;
>   return 1;
> }
> 
> And compiled with the command line
> 
> > avr-gcc pr30338.c -S -Os -dp -mmcu=atmega128 -fdump-tree-original
> 
> pr30338.c: In function 'testload_func':
> pr30338.c:9:11: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
> pr30338.c:10:14: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
> 
> Frist of all, the warning is incorrect because Pmode=HImode=int on AVR.

This is a gcc-help matter, if you have 16-bit int, then obviously
0x20 doesn't fit into signed or unsigned int, and as it fits into
long (which must be 32-bit at least), it has type long int.
See ISO C99, 6.4.4.1.
"The type of an integer constant is the first of the corresponding list in
which its value can be represented."
For no suffix and hexadecimal constant, the list is
{,long ,long long }{,unsigned }int

Jakub

Re: [C]: Unnecessary int(16)->long(32) promotion: Bug in C front end?

[Ian Lance Taylor]

Georg-Johann Lay writes:

> extern char *grub_scratch_mem;
> int testload_func (char *arg, int flags)
> {
>   int i;
>   for (i = 0; i < 0x10ac0; i++)
> if (*((unsigned char *) ((0x20 + i + (int) grub_scratch_mem)))
> != *((unsigned char *) ((0x30 + i + (int) grub_scratch_mem
>   return 0;
>   return 1;
> }
>
> And compiled with the command line
>
>> avr-gcc pr30338.c -S -Os -dp -mmcu=atmega128 -fdump-tree-original
>
> pr30338.c: In function 'testload_func':
> pr30338.c:9:11: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
> pr30338.c:10:14: warning: cast to pointer from integer of different
> size [-Wint-to-pointer-cast]
>
> Frist of all, the warning is incorrect because Pmode=HImode=int on AVR.

The constant 0x20 does not fit in a 16-bit integer.  Therefore the
compiler gives it the type long, as the C standard requires.  The
arithmetic promotion rules then cause the compiler to cast i and
grub_scratch_mem to long, and to do the operation in long.  The warning
then occurs when casting from long to a pointer type.

Ian

Re: [C]: Unnecessary int(16)->long(32) promotion: Bug in C front end?

[Georg-Johann Lay]

Jakub Jelinek wrote:
> On Fri, Jul 08, 2011 at 02:36:23PM +0200, Georg-Johann Lay wrote:
>> I am on 4.7 trunk (175991)
>>
>> Configured with: ../../gcc.gnu.org/trunk/configure --target=avr
>> --prefix=/local/gnu/install/gcc-4.7 --disable-nls --disable-shared
>> --enable-languages=c,c++ --with-dwarf2 --disable-lto
>>
>> Suppose the following source from gcc.c-torture/compile/pr30338.c:
>>
>> extern char *grub_scratch_mem;
>> int testload_func (char *arg, int flags)
>> {
>>   int i;
>>   for (i = 0; i < 0x10ac0; i++)
>> if (*((unsigned char *) ((0x20 + i + (int) grub_scratch_mem)))
>> != *((unsigned char *) ((0x30 + i + (int) grub_scratch_mem
>>   return 0;
>>   return 1;
>> }
>>
>> And compiled with the command line
>>
>>> avr-gcc pr30338.c -S -Os -dp -mmcu=atmega128 -fdump-tree-original
>> pr30338.c: In function 'testload_func':
>> pr30338.c:9:11: warning: cast to pointer from integer of different
>> size [-Wint-to-pointer-cast]
>> pr30338.c:10:14: warning: cast to pointer from integer of different
>> size [-Wint-to-pointer-cast]
>>
>> Frist of all, the warning is incorrect because Pmode=HImode=int on AVR.
> 
> This is a gcc-help matter, if you have 16-bit int, then obviously
> 0x20 doesn't fit into signed or unsigned int, and as it fits into
> long (which must be 32-bit at least), it has type long int.
> See ISO C99, 6.4.4.1.
> "The type of an integer constant is the first of the corresponding list in
> which its value can be represented."
> For no suffix and hexadecimal constant, the list is
> {,long ,long long }{,unsigned }int
> 
>   Jakub

Thanks for clarification.

Johann

Re: Cross compiler build instructions - PowerPC

[Joseph S. Myers]

On Fri, 8 Jul 2011, Rohit Arul Raj wrote:

> Adding "--disable-decimal-float --disable-libffi
> --disable-libquadmath" to configure options gives the same error.

Then you must debug the issue yourself, on the system you are using for 
building, and gain sufficient understanding of the code in the process to 
work out why --disable-decimal-float isn't disabling the build of the 
libdecnumber code for the target.

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

Re: [patches] Re: Cross compiler build instructions - PowerPC

[Khem Raj]

On Fri, Jul 8, 2011 at 1:08 AM, Rohit Arul Raj  wrote:
> On Wed, Mar 23, 2011 at 5:55 PM, Joseph S. Myers
>  wrote:
>> On Wed, 23 Mar 2011, Rohit Arul Raj wrote:
>>
>>> Hello All,
>>>
>>> I have been trying to build a cross compiler (for PowerPC) on x86_64
>>> linux host. I followed the build procedure given in the link below:
>>>
>>> http://www.eglibc.org/archives/patches/msg00078.html
>>
>> You should be referring to the current checked-in version of this
>> documentation, not a four-year-old draft.  However, it doesn't appear to
>> have relevant changes.  Maxim, perhaps we should add
>> --disable-decimal-float --disable-libffi --disable-libquadmath to the
>> configure options for the first GCC in EGLIBC.cross-building?
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com
>>
>
> Any updates on this one yet?
> Adding "--disable-decimal-float --disable-libffi
> --disable-libquadmath" to configure options gives the same error.

I a script based on these instructions which is uptodate and builds eglibc
based toolchains

https://github.com/kraj/ct-scripts/blob/master/toolchain-eglibc.sh

You can try that

>
> Regards,
> Rohit
>

Re: gcc 4.6.1 expand is playing tricks on me

[Michael Matz]

Hi,

On Fri, 8 Jul 2011, Paulo J. Matos wrote:

> gcc4.5.3 hits continue the first time it gets there and gcc4.6.1 fails 
> the inner if and enters expand_gimple_stmt twice.

Yes, the MEMREF branch merge disabled TER (temporary expression 
replacement, tree-ssa-ter.c) for loads with stores that possibly alias, 
because expand doesn't deal correctly with all cases.

Without TERing these two instructions expand won't see both memory 
references at the same time, and hence generate separate load and store 
instruction, instead of a mem-mem move if that's supported on your target 
(I assume so, otherwise you wouldn't have noticed).

The question is, why doesn't combine merge the two separate load and store 
insns again into one?

If you feel adventurous you can try with the below patch.  Test it also 
with the following testcase:
---
char str[9] = "1234";

void
bar (void)
{
  unsigned int temp;
  char *p = &str[2];

  memcpy (&temp, &str[1], 4);
  memcpy (p, &temp, 4);
}
---

If expand still has the problem and you apply the patch, then on some 
targets this will emit wrong instructions because the two sides of the 
MEM-MEM assignment implicitely constructed and given to expand will 
partially overlap.


Ciao,
Michael.
-- 
Index: tree-ssa-ter.c
===
--- tree-ssa-ter.c  (revision 175921)
+++ tree-ssa-ter.c  (working copy)
@@ -638,6 +638,7 @@ find_replaceable_in_bb (temp_expr_table_
 is a load aliasing it avoid creating overlapping
 assignments which we cannot expand correctly.  */
  if (gimple_vdef (stmt)
+ && 0
  && gimple_assign_single_p (stmt))
{
  gimple def_stmt = SSA_NAME_DEF_STMT (use);

Re: gcc 4.6.1 expand is playing tricks on me

[Paulo J. Matos]

On 08/07/11 15:35, Michael Matz wrote:

Without TERing these two instructions expand won't see both memory
references at the same time, and hence generate separate load and store
instruction, instead of a mem-mem move if that's supported on your target
(I assume so, otherwise you wouldn't have noticed).

The question is, why doesn't combine merge the two separate load and store
insns again into one?



I got it! Thanks Michael.
The answer to your last question is that we don't support memory to 
memory moves.


The situation is a bit more complex. When we see
(set (mem:HI (reg:HI 0)) (mem:HI (reg:HI 1)))

we have a rule that expands this to 4 insn
(set (reg:QI AL) (mem:QI (plus (reg:HI 1) (const_int 1
(set (reg:QI AH) (mem:QI (reg:HI 1)))
(set (mem:QI (plus (reg:HI 0) (const_int 1))) (reg:QI AL))
(set (mem:QI (reg:HI 0)) (reg:QI AH))

because we know that using AL and AH as intermediate registers is the 
only way to go in this case. This is then modified slightly by combine, 
etc to generate optimal code.


When GCC 4.6.1 generates two insn dealing with HI so we never have the 
opportunity to introduce these set of 4 insn. The resulting code is less 
than perfect.


However, you hinted to using combine. I am wondering if I can combine 
and into a memory-memory move in HImode and straight away split into the 
4 insn above. In the end 4.6.1 would end up doing the same at combine 
time as 4.5.3 in expand time. I have to look at it once again.


As a last resort I might try your patch, however I try to touch the core 
as little as possible. We already have enough patches to deal with 16 
bit words, chars, wide chars, fn ptrs size != data ptrs size, etc. :)


Thank you very much for your explanation and tips.

Cheers,

Paulo Matos

Re: announce: MELT plugin 0.8rc2 for 4.6

[Basile Starynkevitch]

On Fri, 08 Jul 2011 19:50:11 +1000
Allan McRae  wrote:

> On 08/07/11 19:15, Basile Starynkevitch wrote:
> > On Fri, Jul 08, 2011 at 06:41:30PM +1000, Allan McRae wrote:
> >> empty-file-for-melt.c
> >> cc1: note: MELT is bootstrapping so ignore builtin source directory
> >> /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/melt-source and module
> >> directory
> >> /usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/libexec/melt-modules
> >> *** WARNING *** there are active plugins, do not report this as a
> >> bug unless you can reproduce it without enabling any plugins.
> >> Event| Plugins
> >> PLUGIN_FINISH_UNIT   | melt
> >> PLUGIN_FINISH| melt
> >> PLUGIN_GGC_START | melt
> >> PLUGIN_GGC_MARKING   | melt
> >> PLUGIN_ATTRIBUTES| melt
> >> PLUGIN_START_UNIT| melt
> >> PLUGIN_PRAGMAS   | melt
> >> cc1: internal compiler error: Segmentation fault
> >> Please submit a full bug report,
> >
> >
> > Did you install a previous release of MELT plugin (e.g. 0.8rc1 or 0.7)? If
> > you did, you have to remove it entirely (eg remove all files named *melt*)?
> >
> 


Alexandre Lissy discovered that by replacing, in file
melt-0.8rc2-plugin-for-gcc-4.6/melt-build.mk line 420,
   MELT_STAGE_ZERO?= melt-stage0-dynamic 
with
   MELT_STAGE_ZERO = melt-stage0-static
the bug disappears. 

Allan, could you confirm that it is the case for you also? Thanks!

Cheers.
-- 
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: announce: MELT plugin 0.8rc2 for 4.6

[Basile Starynkevitch]

On Fri, 08 Jul 2011 17:45:39 +0200
Alexandre Lissy  wrote:

> Le 08/07/2011 17:43, Basile Starynkevitch a écrit :
> > On Fri, 08 Jul 2011 19:50:11 +1000
> > Alexandre Lissy discovered that by replacing, in file
> > melt-0.8rc2-plugin-for-gcc-4.6/melt-build.mk line 420,
> >MELT_STAGE_ZERO?= melt-stage0-dynamic 
> > with
> >MELT_STAGE_ZERO = melt-stage0-static
> > the bug disappears. 
> "disappears", I take it as a workaround, not a bug fix :)


Agreed. It is indeed more a workaround than a bug fix.

I probably am able to reproduce that bug, on a chrooted Debian/Sid 32 bits.

(I am not sure I am able to fix it cleverly)

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

Improve addsi3 for CONST_INT

[Georg-Johann Lay]

Denis Chertykov wrote:
> 2011/7/7 Georg-Johann Lay:
>> Hi Denis.
> 
> I think that it's a good question to discuss inside gcc mailing list.
> May be somebody more qualified person give a better suggestion than me.

...bringing this over to gcc mailing list

>> I think about improving addsi3 insn when a const_int is added.
>> The hard case is when the register to add the value is not in "d".
>> In the current implementation the constant simply gets reloaded into
>> some register (provided it is not an "easy" const like 1 or -1).
>>
>> That's a waste because
>>
>> * a 32-bit register gets initialized with the const, but a 8-bit
>>  d-register would be sufficient.
>>
>> * Instead of setting an intermediate register, the value could be
>>  added byte-by-byte if one d-reg was available.
>>
>> A bit unsure about how to approach that, I'd ask you what you think
>> about it.  I can think of three approaches:
>>
>> 1) Use a peep2 on sequence like
>>*reload_insi
>>*addsi3
>>   resp.
>>*movsi
>>*addsi3
>>
>> 2) Add new insn with (clobber (match_scratch:QI "=&d"))
>>
>> 3) Allow all const_int in *addsi3. If peep2 comes up with
>>   a d-clobber, that's fine. Else have to cook up a clobber
>>   by saving a d-reg to tmp_reg similar to movsi implementation.
>>
>> Approach (1) has the advantage that it is "neutral" with respect
>> to reloading.  However, reload will always allocate a SI register,
>> even if peep2 comes up with a scratch.
> 
> But, CSE will always have a chance to optimize it.

You mean CSE or reload-CSE?

If same constant is used multiple times, CSE can arrange for that and
combine can can compose a addsi+clobber. combine will only insert the
constant if it can reduce the number of insns, i.e. if two insns need
the same constant it won't do the replacement.

>> Approach (2) has the advantage that it has just "pressure 1 on d-regs"
>> whilst (1) and the current implementation have "pressure 4 or even
>> r-regs".
> 
> IMHO it's good idea to check.
> 
>> I am in favor of approach (3): It's easier pattern like (1) and it
>> does not put pressure on regs at all.  Also (3) makes no additional
>> work to support SF or if there were fixed-point mode.
> 
> It's a fake.
> Generally, all fake methods is a wrong way. (Look at fake addressing)

Yes, it's a fake.  Bot note that movsi "r,i" alternative is also a
fake, and maybe you remember my failed approach to use secondary
reloads for that:
   http://gcc.gnu.org/ml/gcc/2011-03/msg00290.html

A word on fake addressing (PR46278):

You were right with that.
At the time you wrote the AVR port, there was nothing like
MODE_CODE_BASE_REG_CLASS or REGNO_MODE_CODE_OK_FOR_BASE_P.
And even today it's not possible to specify different costs for
different addressing modes (ADDRESS_COST won't do it because it wors
on anatomy of an address and not on the address reg(s) invented).
If there was a way to tell the costs to IRA/reload and these passes
cared for the costs, fake addressing would be no problem!

There are architectures where
  LOAD R, [A]
resp.
  LOAD R, [B]
do exactly the same but have different costs because A can be used
implicitly and thus yields shorter code.  There's no way to tell it to
the allocator.  All you can do is define reg-alloc-order and hope for
the best.

> I think that I WAS WRONG while I decide to create __zero_reg__ and
> __tmp_reg__. (It was derived from my low qualify at start of EGCS
> hacking)

I thought about that topic already more than once.
I have no idea how it could be done better.

OPTIMIZE_MODE_SWITCHING looks rempting but it runs prior to reload,
and many uses of ZERO or TMP generated in reload or peep2.
We would need a pass with similar abilities running after peep2.

To test in ISR if ZERO or TMP is needed, insn attributes could help.
But the stack layout would have to be changed ad-hoc, new BE-pass was
needed and it's error-prone IMHO.

Introducing new ZERO_REG like R2 would change the ABI and ISR
pro/epilogue would increase even more because some insns
change/restore ZERO.


>> Or do you think the improvement is not needed?
> 
> I vote for 2, but I can be wrong.
> You know the best way ;-) Try all methods and compare results.
> (profile optimizing yourself ;-)
> 
>> Thanks for your recommendation.
> 
> I want to give you a recomendation: please, cleanup the port from
> using immediate numbers as register numbers. (in your patches you
> frequently use it)

I intend to do more backend cleanup, the elfos patch just was the first.

> Please, use constants !
> I forgot to point to them in your last patches.
> e.i.
> 
>   /* We have no clobber reg but need one.  Cook one up.
>  That's cheaper than loading from constant pool.  */
> 
>   cooked_clobber_p = true;
>   clobber_reg = gen_rtx_REG (QImode, 31);
> 
> 
> Use REG_Z + 1 instead of 31.

Already committed:
   http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00634.html

> Few years ago I have an idea to use register renumbering

frame pointer must be single register?

[DJ Delorie]

Is there an unwritten rule that the frame pointer must be a single
hard register?  I'm working on a port where $fp is a register pair,
and I've seen gcc allocate the second register to other things
(causing all sorts of problems).

Re: frame pointer must be single register?

[Paul Koning]

On Jul 8, 2011, at 1:07 PM, DJ Delorie wrote:

> 
> Is there an unwritten rule that the frame pointer must be a single
> hard register?  I'm working on a port where $fp is a register pair,
> and I've seen gcc allocate the second register to other things
> (causing all sorts of problems).

Would it suffice simply to mark the second register as a reserved register?  
That should take it away from the allocator, right?

paul

Re: gcc 4.6.1 expand is playing tricks on me

[Paulo J. Matos]

On 08/07/11 15:58, Paulo J. Matos wrote:

However, you hinted to using combine. I am wondering if I can combine
and into a memory-memory move in HImode and straight away split into the
4 insn above. In the end 4.6.1 would end up doing the same at combine
time as 4.5.3 in expand time. I have to look at it once again.



Just to add that the strategy above worked very well. :)

Re: frame pointer must be single register?

[Jeff Law]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 07/08/11 11:07, DJ Delorie wrote:
> Is there an unwritten rule that the frame pointer must be a single
> hard register?  I'm working on a port where $fp is a register pair,
> and I've seen gcc allocate the second register to other things
> (causing all sorts of problems).
It's certainly caused problems (some of which I believe have been fixed
within the last year or so)...  I think there's a port (AVR?) that may
have similar characteristics.

jeff

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJOFzsGAAoJEBRtltQi2kC7YSkH/20Fa0BrXzM4sfRmwcW53wPe
dCR+s9Th6QvvNuBnV3i+J3p6tq+5pefr4VxtpZaQsJ8cXjxbxJpgtFB9wKH2Avn9
5KIlTufjzXD5wVsXOFxyE2VGgmJn5JLyd4vGPYaUShw4VYFN7XyqJ8N4Gvp+Out2
kfdYD3R5T2Slm2ZKdWMoIFkCE2hb1D9kurWWL6kKE4uSI/5KHJxGDLD2iNrKOq8Y
MiMySxsRy95oxx3Y5c8SyA6Xi02HVTwdCn/orycO/JN569ngRz3IX6JL/zT+GKTA
fYf0KTeeN9FuPItixvdq/MCenvLSUdPJcjxksvK+X8c+hv5v/5gOUZONcrAU0SA=
=rLHD
-END PGP SIGNATURE-

RTEMS Port of GCJ Progress Report

[Jie Liu]

Hi,

This is the second report after “GCJ Porting for RTEMS Status
Report”[1]. During this time, I am
--- Focusing on running the testsuite and fix encountered problem
--- Submitting patches to related community

In details, I have got the testsuite result for boehm-gc, libffi and
libjava, which can be seen in rtemsgcj project’s trunk[2]. For
problems encountered in boehm-gc, they are fixed under Ivan’s help,
and the problems can be seen in mailing list[3](Just search rtems for
related information). For problems encountered in libjava, I have send
a mail to java-patches[4], some problems have been fixed while others
still in fixing.

The patches have been send to related communities, although libjava’s
patch still needs modify. For boehm-gc, the patch can be seen on
java-patches mailing list[5]. For RTEMS, the patch can be seen on
RTEMS mailing list[6]. For libjava, the patch also can be seen on
java-patches mailing list[7]. The libffi is worked on RTEMS/i386, so
there is no patch for it.

Next step, I will
+++ Make as more libjava test case PASS as possible and get the
libjava patch merged
+++ Move to a new architecture and repeat the porting progress

If you have any ideas on this project, please do not hesitate to contact me. :)

[1] http://www.rtems.org/pipermail/rtems-users/2011-June/008574.html
[2]http://rtemsgcj.googlecode.com/svn/trunk/gcjtest/testsuite_out
[3] http://news.gmane.org/gmane.comp.programming.garbage-collection.boehmgc
[4] http://gcc.gnu.org/ml/java-patches/2011-q3/msg00016.html
[5] http://gcc.gnu.org/ml/java-patches/2011-q2/msg00067.html
[6] http://www.rtems.org/pipermail/rtems-users/2011-June/008573.html
[7] http://gcc.gnu.org/ml/java-patches/2011-q3/msg1.html

Best Regards,
Jie

onlinedocs formated text too small to read

[Jon Grant]

Hello

I'm using latest Firefox looking at the onlinedocs with a default
Firefox install, default font sizes, no change in zoom level.

http://gcc.gnu.org/onlinedocs/gcc/Variable-Attributes.html


The monospace text is tiny, e.g.:

  struct foo { int x[2]
__attribute__ ((aligned (8))); };
 


The fix is pretty easy, just change the embedded CSS that is generated:

  pre.smallexample { font-size:smaller }

I propose this be changed to:

  pre.smallexample { font-size:normal }


Note: There are some other CSS tags with "smaller", but they are
unused on that page, perhaps worth checking if the others are used in
other files and can be changed to "normal" as well.

I'm not on the mailing list, so please keep my email address in any replies.

Thanks, Jon

Re: onlinedocs formated text too small to read

[Andrew Pinski]

On Fri, Jul 8, 2011 at 10:50 AM, Jon Grant  wrote:
> Hello
>
> I'm using latest Firefox looking at the onlinedocs with a default
> Firefox install, default font sizes, no change in zoom level.

Are you sure that this is not a bug in Firefox?  I think it is the
correct size for me with the version I am using.

Thanks,
Andrew Pinski

Re: frame pointer must be single register?

[Georg-Johann Lay]

Jeff Law wrote:
> On 07/08/11 11:07, DJ Delorie wrote:
>> Is there an unwritten rule that the frame pointer must be a single
>> hard register?  I'm working on a port where $fp is a register pair,
>> and I've seen gcc allocate the second register to other things
>> (causing all sorts of problems).
> It's certainly caused problems (some of which I believe have been fixed
> within the last year or so)...  I think there's a port (AVR?) that may
> have similar characteristics.
> 
> jeff

Yes, and fixing the second part appears not to be the right approach.
I just committed a patch to fix PR46779, PR45291.

Johann

Re: onlinedocs formated text too small to read

[Paul Koning]

On Jul 8, 2011, at 1:54 PM, Andrew Pinski wrote:

> On Fri, Jul 8, 2011 at 10:50 AM, Jon Grant  wrote:
>> Hello
>> 
>> I'm using latest Firefox looking at the onlinedocs with a default
>> Firefox install, default font sizes, no change in zoom level.
> 
> Are you sure that this is not a bug in Firefox?  I think it is the
> correct size for me with the version I am using.

It depends on what is viewed as correct.  I see a readable page in Safari, but 
it certainly is true that the examples are in rather small typeface and the 
fact that they are readable at all is partly due to the fact that I have a high 
resolution display.

Page layout and typographic design is very much a matter of opinion.  My 
opinion is that I can see no good reason at all for the examples to be in a 
smaller type size than the body text.  So I agree with Jon's change.  Smaller 
type should be used (if ever) for things like footnotes, but not in the body of 
the page.

paul

Re: onlinedocs formated text too small to read

[Georg-Johann Lay]

Andrew Pinski wrote:
> On Fri, Jul 8, 2011 at 10:50 AM, Jon Grant  wrote:
>> Hello
>>
>> I'm using latest Firefox looking at the onlinedocs with a default
>> Firefox install, default font sizes, no change in zoom level.
> 
> Are you sure that this is not a bug in Firefox?  I think it is the
> correct size for me with the version I am using.
> 
> Thanks,
> Andrew Pinski

I can confirm that it's hardly readable on some systems.
I use Opera and several FF versions, some worse, some a bit less worse.

IMO it's definitely to small, I already thought about complaining, too.

Johann

Re: How to force an indirect jump?

[Joern Rennecke]

Quoting Richard Henderson :


On 07/07/2011 06:48 AM, Camo Johnson wrote:

Somehow I was not able to find a way to do so. The main problem is
that I can't find a way to tell the compiler that I need a register
for the indirect jump.


Have a look at the SH target, which has a very similar problem.


A caveat, though: this is a port that used to be highly tuned for
performance, but hasn't seen much TLC recently.
The code that makes use of the bsr instruction for sh-elf relies on
relocation output with -mrelax (some of which was broken the last time
I looked), but is actually located in is in bfd/elf32-sh.c, and the design
is explained in bfd/coff-sh.c .

I suppose a new port would be expected to do this inside gcc with lto,
with some yet to be created/contributed infrastructure for inter-function
branch shortening.

Re: Improve addsi3 for CONST_INT

[Joern Rennecke]

Quoting Georg-Johann Lay :


OPTIMIZE_MODE_SWITCHING looks rempting but it runs prior to reload,
and many uses of ZERO or TMP generated in reload or peep2.
We would need a pass with similar abilities running after peep2.


Actually, optimize_mode_switching used to run after reload, and its
EMIT_HARD_REG_SET interface still bears witness to that - I.e. it
passes you a HARD_REG_SET of live registers.
You could just try if it still works after reload.
You can register additional instances of a pass with a register_pass somewhere
from your port or a plugin.
In fact, I'm currently working on a port with interrelated switchable
entities where I need a total of three instances of pass_mode_switching,
plus two helper passes, to get the kind of optimized mode switching I
set out to get.

Although I'm not quite sure what bearing that has on different hard register
address costs.  I would think a set of memory constraints and
differently-costed alternatives in instruction alternatives would expose the
cost differences to the register allocator and reload.

[pph] cache replace next insert by

[Gabriel Charette]

Hey Diego,

as we just talked over the phone, here is the diff I had sitting in my
stash to ask the pph cache to replace the next cache insert by the
given pointer (while still reading what's in the stream).

To use it simply call pph_cache_replace_next_by(stream, your_new_pointer)
and immediately after call pph_in_(whatever you want to read in and
immediately replace the cache pointer value for).

Cheers,
Gab


pph_cache_replace_next_by.diff
Description: Binary data

gcc-4.6-20110708 is now available

[gccadmin]

Snapshot gcc-4.6-20110708 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110708/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_6-branch 
revision 176064

You'll find:

 gcc-4.6-20110708.tar.bz2 Complete GCC

  MD5=ed8f2b3a1a4e4712b02f5e031b59bb2d
  SHA1=ee2cff29e68a9144fe068da23231db57495f3947

Diffs from 4.6-20110701 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.6
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.

[PATCH, rs6000] -mno-sched-prolog vs .debug_frame

[Richard Henderson]

On 07/05/2011 04:30 PM, David Edelsohn wrote:
> On Fri, Jul 1, 2011 at 8:31 PM, Richard Henderson  wrote:
>> The implementation of TARGET_SCHED_PROLOG is incompatible with
>> some coming changes to how dwarf2 cfi is to be generated.
>>
>> Some suggested solutions are:
>>
>>  (1) Remove the option.  Is it really that interesting
>> beyond -mno-sched-insns2?
>>
>>  (2) Emit blockage insns at the end of the prologue
>> and the beginning of the epilogue.  That'll prevent
>> the majority of the changes that scheduling could
>> introduce.
>>
>>  (3) Emit the prologue and epilogue somewhere after
>> scheduling and before final.  E.g. md_reorg.
>>
>> I'd be delighted if someone could actually implement one
>> of these changes at some point in the next week, but
>> failing that please weigh in on the preferred solution.
> 
> As we discussed on IRC, (1) with and eventual implementation of (2) are okay.

Implements (2).  I emit the blockage in the expanders and not in
rs6000_emit_{pro,epi}logue because the functions contain several
sets of early-returns.  Putting it here avoids any tricky code
rearrangement.

Tested via cross-compile, and as they say, "what could go wrong?"

Ok?


r~
* config/rs6000/rs6000.c (rs6000_output_function_prologue): Don't
try to insert an rtl prologue here.
(rs6000_output_function_epilogue): Similarly.
* config/rs6000/rs6000.md (prologue): Emit a barrier to
satisfy !TARGET_SCHED_PROLOG.
(epilogue, sibcall_epilogue): Likewise.


diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index 475c104..a25e5af 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -20570,39 +20570,6 @@ rs6000_output_function_prologue (FILE *file,
   common_mode_defined = 1;
 }
 
-  if (! HAVE_prologue)
-{
-  rtx prologue;
-
-  start_sequence ();
-
-  /* A NOTE_INSN_DELETED is supposed to be at the start and end of
-the "toplevel" insn chain.  */
-  emit_note (NOTE_INSN_DELETED);
-  rs6000_emit_prologue ();
-  emit_note (NOTE_INSN_DELETED);
-
-  /* Expand INSN_ADDRESSES so final() doesn't crash.  */
-  {
-   rtx insn;
-   unsigned addr = 0;
-   for (insn = get_insns (); insn != 0; insn = NEXT_INSN (insn))
- {
-   INSN_ADDRESSES_NEW (insn, addr);
-   addr += 4;
- }
-  }
-
-  prologue = get_insns ();
-  end_sequence ();
-
-  if (TARGET_DEBUG_STACK)
-   debug_rtx_list (prologue, 100);
-
-  emit_insn_before_noloc (prologue, BB_HEAD (ENTRY_BLOCK_PTR->next_bb),
- ENTRY_BLOCK_PTR);
-}
-
   rs6000_pic_labelno++;
 }
 
@@ -21413,43 +21380,6 @@ static void
 rs6000_output_function_epilogue (FILE *file,
 HOST_WIDE_INT size ATTRIBUTE_UNUSED)
 {
-  if (! HAVE_epilogue)
-{
-  rtx insn = get_last_insn ();
-  /* If the last insn was a BARRIER, we don't have to write anything except
-the trace table.  */
-  if (GET_CODE (insn) == NOTE)
-   insn = prev_nonnote_insn (insn);
-  if (insn == 0 ||  GET_CODE (insn) != BARRIER)
-   {
- /* This is slightly ugly, but at least we don't have two
-copies of the epilogue-emitting code.  */
- start_sequence ();
-
- /* A NOTE_INSN_DELETED is supposed to be at the start
-and end of the "toplevel" insn chain.  */
- emit_note (NOTE_INSN_DELETED);
- rs6000_emit_epilogue (FALSE);
- emit_note (NOTE_INSN_DELETED);
-
- /* Expand INSN_ADDRESSES so final() doesn't crash.  */
- {
-   rtx insn;
-   unsigned addr = 0;
-   for (insn = get_insns (); insn != 0; insn = NEXT_INSN (insn))
- {
-   INSN_ADDRESSES_NEW (insn, addr);
-   addr += 4;
- }
- }
-
- if (TARGET_DEBUG_STACK)
-   debug_rtx_list (get_insns (), 100);
- final (get_insns (), file, FALSE);
- end_sequence ();
-   }
-}
-
 #if TARGET_MACHO
   macho_branch_islands ();
   /* Mach-O doesn't support labels at the end of objects, so if
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 8c0e299..a404448 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -13025,12 +13025,13 @@
 
 (define_expand "sibcall_epilogue"
   [(use (const_int 0))]
-  "TARGET_SCHED_PROLOG"
-  "
+  ""
 {
-  rs6000_emit_epilogue (TRUE);
-  DONE;
-}")
+  if (!TARGET_SCHED_PROLOG)
+emit_insn (gen_blockage ());
+  rs6000_emit_epilogue (TRUE);
+  DONE;
+})
 
 ;; UNSPEC_VOLATILE is considered to use and clobber all hard registers and
 ;; all of memory.  This blocks insns from being moved across this point.
@@ -15791,12 +15792,13 @@
 
 (define_expand "prologue"
   [(use (const_int 0))]
-  "TARGET_SCHED_PROLOG"
-  "
+  ""
 {
-  rs6000_emit_prologue ();
-  DONE;
-}")
+  rs6000_emit_prologue ();
+  if (!TARG

Re: announce: MELT plugin 0.8rc2 for 4.6

[Allan McRae]

On 09/07/11 01:43, Basile Starynkevitch wrote:

On Fri, 08 Jul 2011 19:50:11 +1000
Allan McRae  wrote:


On 08/07/11 19:15, Basile Starynkevitch wrote:

On Fri, Jul 08, 2011 at 06:41:30PM +1000, Allan McRae wrote:

empty-file-for-melt.c
cc1: note: MELT is bootstrapping so ignore builtin source directory
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/melt-source and module
directory
/usr/lib/gcc/i686-pc-linux-gnu/4.6.1/plugin/libexec/melt-modules
*** WARNING *** there are active plugins, do not report this as a
bug unless you can reproduce it without enabling any plugins.
Event| Plugins
PLUGIN_FINISH_UNIT   | melt
PLUGIN_FINISH| melt
PLUGIN_GGC_START | melt
PLUGIN_GGC_MARKING   | melt
PLUGIN_ATTRIBUTES| melt
PLUGIN_START_UNIT| melt
PLUGIN_PRAGMAS   | melt
cc1: internal compiler error: Segmentation fault
Please submit a full bug report,



Did you install a previous release of MELT plugin (e.g. 0.8rc1 or 0.7)? If
you did, you have to remove it entirely (eg remove all files named *melt*)?






Alexandre Lissy discovered that by replacing, in file
melt-0.8rc2-plugin-for-gcc-4.6/melt-build.mk line 420,
MELT_STAGE_ZERO?= melt-stage0-dynamic
with
MELT_STAGE_ZERO = melt-stage0-static
the bug disappears.

Allan, could you confirm that it is the case for you also? Thanks!



I can confirm the build completes with that change.

Allan

Re: [PATCH, rs6000] -mno-sched-prolog vs .debug_frame

[David Edelsohn]

On Fri, Jul 8, 2011 at 8:00 PM, Richard Henderson  wrote:
> On 07/05/2011 04:30 PM, David Edelsohn wrote:
>> On Fri, Jul 1, 2011 at 8:31 PM, Richard Henderson  wrote:
>>> The implementation of TARGET_SCHED_PROLOG is incompatible with
>>> some coming changes to how dwarf2 cfi is to be generated.
>>>
>>> Some suggested solutions are:
>>>
>>>  (1) Remove the option.  Is it really that interesting
>>>     beyond -mno-sched-insns2?
>>>
>>>  (2) Emit blockage insns at the end of the prologue
>>>     and the beginning of the epilogue.  That'll prevent
>>>     the majority of the changes that scheduling could
>>>     introduce.
>>>
>>>  (3) Emit the prologue and epilogue somewhere after
>>>     scheduling and before final.  E.g. md_reorg.
>>>
>>> I'd be delighted if someone could actually implement one
>>> of these changes at some point in the next week, but
>>> failing that please weigh in on the preferred solution.
>>
>> As we discussed on IRC, (1) with and eventual implementation of (2) are okay.
>
> Implements (2).  I emit the blockage in the expanders and not in
> rs6000_emit_{pro,epi}logue because the functions contain several
> sets of early-returns.  Putting it here avoids any tricky code
> rearrangement.
>
> Tested via cross-compile, and as they say, "what could go wrong?"
>
> Ok?

Great!

Thanks, David