Re: GCC Eliminates my Custom RTL ..How to stop this?

[Andrew Haley]

Balaji V. Iyer wrote:

> I am trying to add new RTL into the GCC 4.0.2 OpenRISC port and I am
> trying to insert them into ccertain parts of the instruction stream. For
> testing, I am trying to insert it in the start of every basic block.Here
> is the code for what I am trying to do.
>  
> rtx newInsn = gen_rtx_MY_NEW_INSN(...);
> rtx bbInsn;
>  
> FOR_EACH_BB(bb) {
>bbInsn = BB_HEAD(bb); 
>emit_insn_before(newInsn, bbInsn);
> }
>  
> This code is working fine when we are having no optimization. But when I
> have -O1, -O2 or -O3, the newInsn does'nt appear in every basic block.
> It looks like the optimization phases is deleting this instruction. 
>  
> My question is, how can I "tell" GCC to never remove this instruction
> (or RTL)? This instruction doesn't take any register values or write any
> registers, just accepts an immediate field.

What sort of instruction is it?  Are you using an UNSPEC to model some
special CPU hardware?  gcc will remove instructions that don't do
anything.

Have a look at side_effects_p() in rtlanal.c.

Andrew.

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Joseph S. Myers]

On Sun, 26 Oct 2008, David Edelsohn wrote:

> Graphite's CLooG and PPL libraries use libgmpxx.  Because cc1 is not linked
> by g++, this effectively requires that libgmpxx must be a shared
> library.  libgmp

I hope the Graphite people are working on fixing this for 4.4.  As I said 
in  (following 
Ian's slides), libstdc++ should be statically linked into cc1 by default - 
which probably means that if static libgmpxx is available then it should 
be used.  I'm also concerned that we still don't have any documentation in 
install.texi concerning these libraries and pointing to suitable release 
tarballs of them in the infrastructure directory - we're nearly two months 
into Stage 3 and these libraries should be subject to much the same 
development stage rules as in-tree optimizers with the versions documented 
to be used and associated configure checks changing only to update to new 
bug-fix minor releases, not major feature releases, while in Stage 3.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Richard Guenther]

On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Sun, 26 Oct 2008, David Edelsohn wrote:
>
>> Graphite's CLooG and PPL libraries use libgmpxx.  Because cc1 is not linked
>> by g++, this effectively requires that libgmpxx must be a shared
>> library.  libgmp
>
> I hope the Graphite people are working on fixing this for 4.4.  As I said
> in  (following
> Ian's slides), libstdc++ should be statically linked into cc1 by default -
> which probably means that if static libgmpxx is available then it should
> be used.  I'm also concerned that we still don't have any documentation in
> install.texi concerning these libraries and pointing to suitable release
> tarballs of them in the infrastructure directory - we're nearly two months
> into Stage 3 and these libraries should be subject to much the same
> development stage rules as in-tree optimizers with the versions documented
> to be used and associated configure checks changing only to update to new
> bug-fix minor releases, not major feature releases, while in Stage 3.

I think we are still waiting for the final ppl release, but otherwise
I agree that
instructions and tarballs should be provided rather yesterday than tomorrow.
I don't necessarily agree with statically linking libstdc++ into cc1 - do you
expect problems with linking dynamically?  Static libraries for libgmpxx or
ppl or cloog are usually not available due to size and their libstdc++
requirement.

Richard.

> --
> Joseph S. Myers
> [EMAIL PROTECTED]
>

spill failure with SMALL_REGISTER_CLASSES

[Unruh, Erwin]

Hello,

I have a problem with reload. I am working on a private variation of the i386
port. I am using GCC 4.1.2.

The insn

(insn 38 36 39 1 x.c:30 (parallel [
(set (reg:SI 2 cx [80])
(ashift:SI (reg:SI 6 bp [81])
(subreg:QI (reg:SI 1 dx [78]) 3)))
(clobber (reg:CC 17 flags))
]) 409 {*ashlsi3_1} (insn_list:REG_DEP_TRUE 36 (nil))
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:SI 1 dx [78])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)

gets the reloads

Reloads for insn # 38
Reload 0: reload_in (SI) = (reg:SI 6 bp [81])
reload_out (SI) = (reg:SI 2 cx [80])
GENERAL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (reg:SI 6 bp [81])
reload_out_reg: (reg:SI 2 cx [80])
reload_reg_rtx: (reg:SI 2 cx [80])
Reload 1: reload_in (QI) = (reg:QI 1 dx)
CREG, RELOAD_FOR_INPUT (opnum = 2), can't combine
reload_in_reg: (subreg:QI (reg:SI 1 dx [78]) 3)

and reload fails later down beacuse it cannot find a register for the Reload 1.
The register "cx" is the only register in class CREG, and it is already taken
for Reload 0.

That Reload has class GENERAL_REGS, but find_dummy_reload decided to use the
output register as the reload register.

What is the best correction for the problem? I can think of three possible
solutions:
1. Avoid using a critical register in find_dummy_reload. Before choosing the
   register check whether it is in a small register class.
2. In find_reload_regs, recover from a situation when no register could be
   found. Remove the reload registers already fixed by find_dummy_reload and try
   again.
3. Have an additional check between find_reloads and find_reload_regs. Check
   whether any reload class is a small register class. If so, check the other
   reloads whether they have taken a register of that class. Remove the register
   assignment in case of a conflict.

Thanks in advance,

Erwin

--
Erwin Unruh
IP SW LP AD 2
Fujitsu Siemens Computers GmbH
Domagkstrasse 28
D-80807 München

Telefon:+49 (0)89 3222 3825
Telefax:+49 (0)89 3222 3802
Email:  mailto:[EMAIL PROTECTED]
Internet:   http://www.fujitsu-siemens.de
Firmenangaben:  http://www.fujitsu-siemens.de/imprint.html

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[David Edelsohn]

On Mon, Oct 27, 2008 at 8:22 AM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Sun, 26 Oct 2008, David Edelsohn wrote:
>
>> Graphite's CLooG and PPL libraries use libgmpxx.  Because cc1 is not linked
>> by g++, this effectively requires that libgmpxx must be a shared
>> library.  libgmp
>
> I hope the Graphite people are working on fixing this for 4.4.  As I said
> in  (following
> Ian's slides), libstdc++ should be statically linked into cc1 by default -
> which probably means that if static libgmpxx is available then it should
> be used.

I disagree; this is a very bad suggestion and will introduce more breakage.
Statically linking libstdc++ breaks some architectures.

If and when GCC itself is C++, it can be linked with libstdc++.  Until then,
there is no reason the dependencies of libraries should be propagated
to cc1 itself.

Graphite will be a technology preview in GCC 4.4, with the associated
volatility.

David

Cannot generate profile data, it's weird, thank you

[Qi齐辉 Hui]

Hi folks,

I encountered an weird issue when I using gcc 3.4.6 to build our
project. The profile data (*.gcda files)can not be generated or be
updated when the binary is running as 1 process, only be generated or
be updated with 2 processes when I set the process number as 2 in the
configure file. The configure options are exactly same except the
number of  PROCESS. (-fprofile-generate)

I am so confused. I have exactly same configure files, same code
source, same machine and same environment, And this issue never
happened when I was using gcc 3.2.3.

I was trying to write a demo programme to reproduce it, but I failed,
and I have no ideas what happened? So I write to you for help, please
tell me any possibilities may lead this issue happen?

Thank you very much
rgds
Hui

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Joseph S. Myers]

On Mon, 27 Oct 2008, Richard Guenther wrote:

> On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
> <[EMAIL PROTECTED]> wrote:
> > On Sun, 26 Oct 2008, David Edelsohn wrote:
> >
> >> Graphite's CLooG and PPL libraries use libgmpxx.  Because cc1 is not linked
> >> by g++, this effectively requires that libgmpxx must be a shared
> >> library.  libgmp
> >
> > I hope the Graphite people are working on fixing this for 4.4.  As I said
> > in  (following
> > Ian's slides), libstdc++ should be statically linked into cc1 by default -
> > which probably means that if static libgmpxx is available then it should
> > be used.  I'm also concerned that we still don't have any documentation in
> > install.texi concerning these libraries and pointing to suitable release
> > tarballs of them in the infrastructure directory - we're nearly two months
> > into Stage 3 and these libraries should be subject to much the same
> > development stage rules as in-tree optimizers with the versions documented
> > to be used and associated configure checks changing only to update to new
> > bug-fix minor releases, not major feature releases, while in Stage 3.
> 
> I think we are still waiting for the final ppl release, but otherwise
> I agree that
> instructions and tarballs should be provided rather yesterday than tomorrow.
> I don't necessarily agree with statically linking libstdc++ into cc1 - do you
> expect problems with linking dynamically?  Static libraries for libgmpxx or
> ppl or cloog are usually not available due to size and their libstdc++
> requirement.

The first and most important step is to support linking with static 
versions of ppl, cloog, gmp, gmpxx, mpfr.  Linking with separately built 
static versions of GMP and MPFR is clearly something widely done as where 
OS versions are available at all they may often be too old and this should 
work just as well for the other libraries, and using static versions 
avoids all problems with the compiler binaries depending on shared 
libraries in nonstandard paths.

The comments above suggest this is broken for the new libraries used by 
Graphite - presumably because of not linking with -lstdc++ so it can only 
be found through shared library dependencies, though they don't specify 
this.  If that is the case then the configure support needs to know to add 
-lstdc++ when linking with these libraries using GCC.

Next is the static libstdc++ - my suggest was that *if static Cloog/PPL 
are being used* then so should static libstdc++, though this could be 
controlled with a configure option.  (One might note that the Ada 
compilers are linked with static versions of the Ada libraries by default; 
I'm sure there are cases where linking with the shared libraries would be 
safe, but the default is for the binaries not to depend on the shared 
libraries.)  Linking with static libstdc++ avoids the binaries depending 
on a shared library that again may not be a system library (especially if 
you follow the procedure some people have suggested of building cross 
compilers always with a native compiler of the same version, which may 
avoid some problems with bootstrap compiler bugs - the context in which 
it's been suggested - but would also potentially introduce dependence of 
one compiler installation on shared libraries in another).

Following that is the problem gcc-in-cxx will need to solve, of 
bootstrapping libstdc++ so each stage's compiler binaries can be linked 
with the previous stage's libstdc++ and a compiler using libstdc++.so.6 
can bootstrap one using libstdc++.so.7 (which may also require the ability 
to build PPL in-tree in order to bootstrap it across incompatible C++ 
library ABIs).  Linking the compiler binaries with static libstdc++ 
certainly simplifies some of the bootstrap issues there.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

RE: GCC Eliminates my Custom RTL ..How to stop this?

[Balaji V. Iyer]

Thank you for your response Andrew.

This is what I am trying to achieve. I want to indicate to my processor
at certain points of execution to do certain control behavior. I am
trying to do this by inserting a specialized instruction that will do
so. 

I am not using the unspec model. I created a new RTL in rtl.def, then I
am inserting that RTL at fixed points of my code, and have a constraint
in my .md file to catch that RTL and convert it into an instruction.

Any help is highly appreciated! 


Please CC me in your response since I am not subscribed to this account.

Thanks,

Balaji V. Iyer.


-- 
 
Balaji V. Iyer
PhD Candidate, 
Center for Efficient, Scalable and Reliable Computing,
Department of Electrical and Computer Engineering,
North Carolina State University.


-Original Message-
From: Andrew Haley [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 27, 2008 6:07 AM
To: Balaji V. Iyer
Cc: gcc@gcc.gnu.org
Subject: Re: GCC Eliminates my Custom RTL ..How to stop this?

Balaji V. Iyer wrote:

> I am trying to add new RTL into the GCC 4.0.2 OpenRISC port and I 
> am trying to insert them into ccertain parts of the instruction 
> stream. For testing, I am trying to insert it in the start of every 
> basic block.Here is the code for what I am trying to do.
>  
> rtx newInsn = gen_rtx_MY_NEW_INSN(...); rtx bbInsn;
>  
> FOR_EACH_BB(bb) {
>bbInsn = BB_HEAD(bb); 
>emit_insn_before(newInsn, bbInsn);
> }
>  
> This code is working fine when we are having no optimization. But when

> I have -O1, -O2 or -O3, the newInsn does'nt appear in every basic
block.
> It looks like the optimization phases is deleting this instruction. 
>  
> My question is, how can I "tell" GCC to never remove this instruction 
> (or RTL)? This instruction doesn't take any register values or write 
> any registers, just accepts an immediate field.

What sort of instruction is it?  Are you using an UNSPEC to model some
special CPU hardware?  gcc will remove instructions that don't do
anything.

Have a look at side_effects_p() in rtlanal.c.

Andrew.

Re: GCC Eliminates my Custom RTL ..How to stop this?

[Ian Lance Taylor]

"Balaji V. Iyer" <[EMAIL PROTECTED]> writes:

> I am not using the unspec model. I created a new RTL in rtl.def, then I
> am inserting that RTL at fixed points of my code, and have a constraint
> in my .md file to catch that RTL and convert it into an instruction.

Your RTL must describe its inputs and outputs.  If the outputs are not
used anywhere, gcc will delete the instruction.  If you can not
properly describe the outputs in RTL, you must write your insn using
an unspec_volatile.

Ian

Re: GCC Eliminates my Custom RTL ..How to stop this?

[Andrew Haley]

Balaji V. Iyer wrote:

> This is what I am trying to achieve. I want to indicate to my processor
> at certain points of execution to do certain control behavior. I am
> trying to do this by inserting a specialized instruction that will do
> so. 
> 
> I am not using the unspec model. I created a new RTL in rtl.def, then I
> am inserting that RTL at fixed points of my code, and have a constraint
> in my .md file to catch that RTL and convert it into an instruction.

That isn't going to work unless you tell gcc what your magic instruction
does.  I suggest you use an UNSPEC_VOLATILE.

Andrew.

new mirror

[Adriaticus]

welcome
I would like to create mirror gcc
http://mirror.adriaticus.org/pub/gcc/
ftp://mirror.adriaticus.org/pub/gcc/
Location:
Germany/Gunzenhausen
Email
[EMAIL PROTECTED]
Regards
Paul

Re: simplify_subreg vs gen_rtx_SUBREG vis WORDS_BIG_ENDIAN

[DJ Delorie]

> One thing to do is to call simplify_gen_subreg.

As I noted, that may return NULL, which is fatal in the case I'm
referencing.

> But I don't think that will help.  I think this code is simply
> incorrect.  It seems to assume that op_mode is at least as large as
> GET_MODE (xop0), probably because that will be the case on the m68k.

Do we want to just fail that function if we detect the
smaller-than-mode case?  Otherwise, I've been using the below function
to constuct endian-aware subregs, it seems to work.

Of course, none of this answers my original question: what's the
"right" way to form a subreg these days?


static rtx
gen_low_word_subreg (enum machine_mode omode, rtx op, enum machine_mode imode)
{
  int lbyte;

  lbyte = GET_MODE_SIZE (imode) - GET_MODE_SIZE (omode);

  if (! BYTES_BIG_ENDIAN || lbyte < 0)
return gen_rtx_SUBREG (omode, op, 0);

  return gen_rtx_SUBREG (omode, op, lbyte);
}

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Roberto Bagnara]

Richard Guenther wrote:

On Mon, Oct 27, 2008 at 1:22 PM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:

On Sun, 26 Oct 2008, David Edelsohn wrote:


Graphite's CLooG and PPL libraries use libgmpxx.  Because cc1 is not linked
by g++, this effectively requires that libgmpxx must be a shared
library.  libgmp

I hope the Graphite people are working on fixing this for 4.4.  As I said
in  (following
Ian's slides), libstdc++ should be statically linked into cc1 by default -
which probably means that if static libgmpxx is available then it should
be used.  I'm also concerned that we still don't have any documentation in
install.texi concerning these libraries and pointing to suitable release
tarballs of them in the infrastructure directory - we're nearly two months
into Stage 3 and these libraries should be subject to much the same
development stage rules as in-tree optimizers with the versions documented
to be used and associated configure checks changing only to update to new
bug-fix minor releases, not major feature releases, while in Stage 3.


I think we are still waiting for the final ppl release, but otherwise
I agree that
instructions and tarballs should be provided rather yesterday than tomorrow.


The first release candidate of the PPL has just been published:

http://www.cs.unipr.it/pipermail/ppl-announce/2008/20.html

If you want, I can draft a patch for install.texi during next weekend.
All the best,

Roberto

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:[EMAIL PROTECTED]

Re: simplify_subreg vs gen_rtx_SUBREG vis WORDS_BIG_ENDIAN

[Ian Lance Taylor]

DJ Delorie <[EMAIL PROTECTED]> writes:

>> One thing to do is to call simplify_gen_subreg.
>
> As I noted, that may return NULL, which is fatal in the case I'm
> referencing.

You mentioned simplify_subreg.  simplify_gen_subreg will only return
NULL when the RTL is already bogus.


>> But I don't think that will help.  I think this code is simply
>> incorrect.  It seems to assume that op_mode is at least as large as
>> GET_MODE (xop0), probably because that will be the case on the m68k.
>
> Do we want to just fail that function if we detect the
> smaller-than-mode case?  Otherwise, I've been using the below function
> to constuct endian-aware subregs, it seems to work.

I think that something like your function is correct, except that it
should call simplify_gen_subreg rather than gen_rtx_SUBREG.

Ian

Re: simplify_subreg vs gen_rtx_SUBREG vis WORDS_BIG_ENDIAN

[DJ Delorie]

Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> simplify_gen_subreg will only return NULL when the RTL is already
> bogus.

Be that as it may, but it was returning NULL in my case.  (I tried
calling simplify_gen_subreg too).

The code in expmed.c seemed to be OK with generating bogus subregs,
assuming that something else will reject them or they'll get fixed
later.

Possible optimizer bug?

[Peter A. Felvegi]

Hello all,

I've run today into an infinite loop when compiled a test suite w/ 
optimizations. The original tests were to do some loops with all the 
nonnegative values of some integral types. Instead of hardwiring the 
max values, I thought testing for overflow into the negative domain is 
ok.


Here is the source to reproduce the bug:

8<8<8<8<
#include 
#include 

int f(int(*ff)(int))
{
int8_t i = 0; /* the real loop counter */
int ii = 0; /* loop counter for the test */
do {
if (ff(ii)) { /* test ii through a fn ptr call */
printf("ouch!\n"); /* too many loops */
return ii;
}
++ii;
} while (++i > 0);
/*
 * the loop should stop when i overflows from 0x7f to
 * 0x80 (ie -128) : 128 iterations
 * if optimizations are enabled, it won't stop.
 */
return 0;
}

extern int g_tr;

int foo(int i)
{
return i > g_tr;
}

int main(void)
{
f(&foo);

return 0;
}

int g_tr = 0x200;
8<8<8<8<

The call through the function pointer to test the loop counter is only for 
disabling inlining. If i put everything into f(), it just prints "ouch" 
and returns 0x201, the loop is optimized away completely.


The expected behaviour is present (stopping after 128 iterations) if 
compiled w/ -O0 or -O1, however, -O2 and above, and -Os result in an 
infinite loop.


The disassembly has an unconditional jump instruction after incrementing 
the loop counter.


Tested on: Debian Lenny (i386 and amd64), gcc 4.1, 4.2 and 4.3.

Compile as:
$ gcc -g -O2 t.c

then run as
$ ./a.out

Is the above code considered illegal, or is it an issue with the 
optimizer?


Regards, Peter

Re: Possible optimizer bug?

[Daniel Berlin]

On Mon, Oct 27, 2008 at 5:57 PM, Peter A. Felvegi
<[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I've run today into an infinite loop when compiled a test suite w/
> optimizations. The original tests were to do some loops with all the
> nonnegative values of some integral types. Instead of hardwiring the max
> values, I thought testing for overflow into the negative domain is ok.
>
> Here is the source to reproduce the bug:
>
> 8<8<8<8<
> #include 
> #include 
>
> int f(int(*ff)(int))
> {
>int8_t i = 0; /* the real loop counter */
>int ii = 0; /* loop counter for the test */
>do {
>if (ff(ii)) { /* test ii through a fn ptr call */
>printf("ouch!\n"); /* too many loops */
>return ii;
>}
>++ii;
>} while (++i > 0);
>/*
> * the loop should stop when i overflows from 0x7f to
> * 0x80 (ie -128) : 128 iterations
> * if optimizations are enabled, it won't stop.
> */
>return 0;
> }
>
> extern int g_tr;
>
> int foo(int i)
> {
>return i > g_tr;
> }
>
> int main(void)
> {
>f(&foo);
>
>return 0;
> }
>
> int g_tr = 0x200;
> 8<8<8<8<
>
> The call through the function pointer to test the loop counter is only for
> disabling inlining. If i put everything into f(), it just prints "ouch" and
> returns 0x201, the loop is optimized away completely.
>
> The expected behaviour is present (stopping after 128 iterations) if
> compiled w/ -O0 or -O1, however, -O2 and above, and -Os result in an
> infinite loop.
>
> The disassembly has an unconditional jump instruction after incrementing the
> loop counter.
>
> Tested on: Debian Lenny (i386 and amd64), gcc 4.1, 4.2 and 4.3.
>
> Compile as:
> $ gcc -g -O2 t.c
>
> then run as
> $ ./a.out
>
> Is the above code considered illegal, or is it an issue with the optimizer

It's illegal.
Signed overflow is undefined.
if you want to guarantee wraparound, use -fwrapv or unsigned math.

Re: simplify_subreg vs gen_rtx_SUBREG vis WORDS_BIG_ENDIAN

[DJ Delorie]

> One thing to do is to call simplify_gen_subreg.  I don't know why this
> code still calls gen_rtx_SUBREG.  It's pretty old code.
> 
> But I don't think that will help.  I think this code is simply
> incorrect.  It seems to assume that op_mode is at least as large as
> GET_MODE (xop0), probably because that will be the case on the m68k.

How about something like this?  It calls simplify_gen_subreg() but
uses the return value to determine if the overall attempt (that "if"
clause) should fail.  Another option is to cause the whole function to
fail, but that seemed overkill.  I'm also not too happy about using a
goto here (not that I'm philosophically against them, but in this case
it seems awkward).

In our internal tree it seems to help H8/300SX quite a bit.

Index: expmed.c
===
--- expmed.c(revision 141404)
+++ expmed.c(working copy)
@@ -681,17 +681,26 @@ store_bit_field_1 (rtx str_rtx, unsigned
   if (MEM_P (xop0))
xop0 = adjust_address (xop0, byte_mode, offset);
 
   /* If xop0 is a register, we need it in OP_MODE
 to make it acceptable to the format of insv.  */
   if (GET_CODE (xop0) == SUBREG)
-   /* We can't just change the mode, because this might clobber op0,
-  and we will need the original value of op0 if insv fails.  */
-   xop0 = gen_rtx_SUBREG (op_mode, SUBREG_REG (xop0), SUBREG_BYTE (xop0));
+   {
+ /* We can't just change the mode, because this might clobber op0,
+and we will need the original value of op0 if insv fails.  */
+ //xop0 = gen_rtx_SUBREG (op_mode, SUBREG_REG (xop0), SUBREG_BYTE 
(xop0));
+ xop0 = simplify_gen_subreg (op_mode, xop0, GET_MODE (xop0), 0);
+ if (!xop0)
+   goto cannot_use_insv_1;
+   }
   if (REG_P (xop0) && GET_MODE (xop0) != op_mode)
-   xop0 = gen_rtx_SUBREG (op_mode, xop0, 0);
+   {
+ xop0 = simplify_gen_subreg (op_mode, xop0, GET_MODE (xop0), 0);
+ if (!xop0)
+   goto cannot_use_insv_1;
+   }
 
   /* On big-endian machines, we count bits from the most significant.
 If the bit field insn does not, we must invert.  */
 
   if (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN)
xbitpos = unit - bitsize - xbitpos;
@@ -749,12 +758,13 @@ store_bit_field_1 (rtx str_rtx, unsigned
{
  emit_insn (pat);
  return true;
}
   delete_insns_since (last);
 }
+ cannot_use_insv_1:
 
   /* If OP0 is a memory, try copying it to a register and seeing if a
  cheap register alternative is available.  */
   if (HAVE_insv && MEM_P (op0))
 {
   enum machine_mode bestmode;
@@ -1492,13 +1502,17 @@ extract_bit_field_1 (rtx str_rtx, unsign
   rtx xspec_target_subreg = 0;
   rtx pat;
 
   /* If op0 is a register, we need it in EXT_MODE to make it
 acceptable to the format of ext(z)v.  */
   if (REG_P (xop0) && GET_MODE (xop0) != ext_mode)
-   xop0 = gen_rtx_SUBREG (ext_mode, xop0, 0);
+   {
+ xop0 = simplify_gen_subreg (ext_mode, xop0, GET_MODE (xop0), 0);
+ if (!xop0)
+   goto cannot_use_extv_1;
+   }
   if (MEM_P (xop0))
/* Get ref to first byte containing part of the field.  */
xop0 = adjust_address (xop0, byte_mode, xoffset);
 
   /* On big-endian machines, we count bits from the most significant.
 If the bit field insn does not, we must invert.  */
@@ -1546,12 +1560,13 @@ extract_bit_field_1 (rtx str_rtx, unsign
  if (xtarget == xspec_target_subreg)
return xspec_target;
  return convert_extracted_bit_field (xtarget, mode, tmode, unsignedp);
}
   delete_insns_since (last);
 }
+ cannot_use_extv_1:
 
   /* If OP0 is a memory, try copying it to a register and seeing if a
  cheap register alternative is available.  */
   if (ext_mode != MAX_MACHINE_MODE && MEM_P (op0))
 {
   enum machine_mode bestmode;

Matching delete operator overload as a template function

[S. Tang]

Hello there,

>From what I understand, if one uses placement new with a parameter to 
>initialize a class, and if that class' constructor throws an exception, then a 
>matching delete operator is called to release the memory. 

This does not seem to work if the overloaded delete operator is a template 
function.

I wrote a test program as follows:

== code ==
#include 
#include 

class MyClass
{
public:
  MyClass() { throw 1; } // constructor throws exception
};

class Pool1
{
public:
  void *Alloc(size_t size) {
printf("Pool1::Alloc()\n");
return malloc(size);
  }

  void Free(void *p) {
printf("Pool1::Free()\n");
return free(p);
  }
};

template
class Pool2
{
public:
  void *Alloc(size_t size) {
printf("Pool2::Alloc()\n");
return malloc(size);
  }

  void Free(void *p) {
printf("Pool2::Free()\n");
return free(p);
  }
};

inline void *operator new(size_t size,Pool1& pool)
{
  return pool.Alloc(size);
}

inline void operator delete(void *p,Pool1& pool)
{
  return pool.Free(p);
}

template
inline void *operator new(size_t size,Pool2& pool)
{
  return pool.Alloc(size);
}

template
inline void operator delete(void *p,Pool2& pool)
{
  return pool.Free(p);
}

int main (int argc, char * const argv[]) {
  Pool1 pool1;
  Pool2 pool2;

  try {
MyClass *myclass = new (pool1) MyClass(); // OK!
  } catch(...) { }

  try {
MyClass *myclass = new (pool2) MyClass(); // delete not called!
  } catch(...) { }

  return 0;
}

== end code ==

The output I get is:
Pool1::Alloc()
Pool1::Free()
Pool2::Alloc()

on gcc 4.2.4 (Ubuntu Hardy Heron) and gcc 4.0.1 Mac OS X.

The expected output is:
Pool1::Alloc()
Pool1::Free()
Pool2::Alloc()
Pool2::Free()

as produced with Visual Studio.

Is the usage of the delete operator as a template function incorrect or is this 
a bug?

Thanks for the help!

Re: [PATCH]: bump minimum MPFR version, (includes some fortran bits)

[Hans-Peter Nilsson]

On Sun, 26 Oct 2008, Geoff Keating wrote:
> Does everyone really type --with-mpfr= on every build?

While we're listing practices, and since nobody's listed it,
lest people think that method isn't used, mine is to *always
build with in-tree gmp and mpfr*: whether at the compile farm,
in a packaged toolchain (glorified source tarball), while
developing, while running my autotester for CRIS, at home,
whereever.

brgds, H-P
PS. Hi, Angela!