Re: GCC 4.7.0RC: Mangled names in cc1
Hi, Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> Ian Lance Taylor skribis: >> >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >>> Ian Lance Taylor skribis: > ludovic.cour...@inria.fr (Ludovic Courtès) writes: > >> However, this means that plug-ins must now be built with g++, except >> when GCC was configured with --disable-build-poststage1-with-cxx. This >> seems difficult to deal with, for plug-in writers. > > This is an unfortunate truth during our transition to building gcc with > C++. There is going to be a period of time when the compiler may be > built as either C or C++. The end goal is for the compiler to always be > built with C++, but until we reach that state I think plugin writers > will have to test. What about wrapping the C API in extern "C"? >>> >>> We eventually will want the internal APIs to be C++, so this transition >>> will inevitably happen at some point. >> >> I understand the goal. However, should a C++ API be added, the C-only >> part could still be kept extern "C". > > We are talking here about internal GCC functions. We are not talking > about an actual defined API. The defined API is in plugin-api.h, and > that remains extern "C". There is no "C-only part" of the internal API. Hmm is for linker plug-ins; provides nothing more than the event mechanism. Symbols declared in are mangled, for instance. I’m not sure whether is considered internal or not, but I can hardly see what kind of plug-in could be written without using it. >> For 4.7.0, as Duncan Sands writes, it would be a very helpful for the >> ABI to be independent of configuration options–i.e., either mangled or >> unmangled symbols. > > That just postpones the pain to gcc 4.8.0. In 4.8 things will be easier: plug-ins will have to be compiled with g++. In 4.7, finding out whether gcc or g++ should be used is left as an exercise to the plug-in writer, which is inconvenient at best. Thanks, Ludo’.
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On Wed, 7 Mar 2012, NightStrike wrote: > On Fri, Mar 2, 2012 at 8:44 AM, Richard Guenther wrote: > > > > GCC 4.7.0 Release Candidate available from gcc.gnu.org > > > > The first release candidate for GCC 4.7.0 is available from > > > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 > > > > and shortly its mirrors. It has been generated from SVN revision 184777. > > > > I have so far bootstrapped and tested the release candidate on > > x86_64-linux. Please test it and report any issues to bugzilla. > > > > If all goes well, I'd like to release 4.7.0 in about three weeks. > > > Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step > with the current version of mpfr version 3.1.0, out since last > October, and mpc, version 0.9, out since Feb of 2011. I'm guessing > the sources moved or something. > > For instance, just to get the configure step to pass, I had to change > the last line of the configure step in the generated Makefile from > this: > > --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp > --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs > --with-mpfr-include=$$s/mpfr > --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs > > to this: > > --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp > --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs > --with-mpfr-include=$$s/mpfr/src > --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs > > > The key section is adding /src on the end of --with-mpfr-include=$$s/mpfr/src > > > That gets the build further, but it still doesn't work. > > This same problem affects 4.6. The suggested versions of the packages in doc/install.texi are older than the ones you tried. Feel free to propose a patch for trunk, changing the recommended versions there. Richard.
Federal Tax Transfer Canceled #49190323
âÈ14-0057395-13730678-3-230
Re: gcc-4.3-20120304 is now available
On Wed, Mar 7, 2012 at 10:00 PM, Gerald Pfeifer wrote: > On Sun, 4 Mar 2012, gccad...@gcc.gnu.org wrote: >> Snapshot gcc-4.3-20120304 is now available on >> ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20120304/ > > What happened here? Some collateral damage while getting the > GCC 4.7 branch set up? Yes, I changed and installed crontab from SVN but appearantly there were local changes not reflected in that from the 4.3 branch closing time (thus, probably my own error). Richard. > Gerald
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On Mon, Mar 12, 2012 at 5:59 AM, Richard Guenther wrote: > On Wed, 7 Mar 2012, NightStrike wrote: > >> On Fri, Mar 2, 2012 at 8:44 AM, Richard Guenther wrote: >> > >> > GCC 4.7.0 Release Candidate available from gcc.gnu.org >> > >> > The first release candidate for GCC 4.7.0 is available from >> > >> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 >> > >> > and shortly its mirrors. It has been generated from SVN revision 184777. >> > >> > I have so far bootstrapped and tested the release candidate on >> > x86_64-linux. Please test it and report any issues to bugzilla. >> > >> > If all goes well, I'd like to release 4.7.0 in about three weeks. >> >> >> Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step >> with the current version of mpfr version 3.1.0, out since last >> October, and mpc, version 0.9, out since Feb of 2011. I'm guessing >> the sources moved or something. >> >> For instance, just to get the configure step to pass, I had to change >> the last line of the configure step in the generated Makefile from >> this: >> >> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp >> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs >> --with-mpfr-include=$$s/mpfr >> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs >> >> to this: >> >> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp >> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs >> --with-mpfr-include=$$s/mpfr/src >> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs >> >> >> The key section is adding /src on the end of --with-mpfr-include=$$s/mpfr/src >> >> >> That gets the build further, but it still doesn't work. >> >> This same problem affects 4.6. > > The suggested versions of the packages in doc/install.texi are > older than the ones you tried. > > Feel free to propose a patch for trunk, changing the recommended > versions there. > > Richard. Ok. But does that mean that to fix configure, we have to increase the minimum version of mpfr?
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
> On Mon, Mar 12, 2012 at 5:59 AM, Richard Guenther wrote: >> On Wed, 7 Mar 2012, NightStrike wrote: >> >>> On Fri, Mar 2, 2012 at 8:44 AM, Richard Guenther wrote: >>> > >>> > GCC 4.7.0 Release Candidate available from gcc.gnu.org >>> > >>> > The first release candidate for GCC 4.7.0 is available from >>> > >>> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 >>> > >>> > and shortly its mirrors. It has been generated from SVN revision 184777. >>> > >>> > I have so far bootstrapped and tested the release candidate on >>> > x86_64-linux. Please test it and report any issues to bugzilla. >>> > >>> > If all goes well, I'd like to release 4.7.0 in about three weeks. >>> >>> >>> Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step >>> with the current version of mpfr version 3.1.0, out since last >>> October, and mpc, version 0.9, out since Feb of 2011. I'm guessing >>> the sources moved or something. >>> >>> For instance, just to get the configure step to pass, I had to change >>> the last line of the configure step in the generated Makefile from >>> this: >>> >>> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp >>> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs >>> --with-mpfr-include=$$s/mpfr >>> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs >>> >>> to this: >>> >>> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp >>> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs >>> --with-mpfr-include=$$s/mpfr/src >>> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs >>> >>> >>> The key section is adding /src on the end of >>> --with-mpfr-include=$$s/mpfr/src >>> >>> >>> That gets the build further, but it still doesn't work. >>> >>> This same problem affects 4.6. >> >> The suggested versions of the packages in doc/install.texi are >> older than the ones you tried. >> >> Feel free to propose a patch for trunk, changing the recommended >> versions there. >> >> Richard. > > Ok. But does that mean that to fix configure, we have to increase the > minimum version of mpfr? I have tested builds of gmp/mpfr/mpc on : 1) x86_64-Linux2.6.18-274.17.1.el5 2) x86_64-Linux2.6.32-220.4.1.el6.x86_64 3) sparc-SunOS5.10 4) plus various others ( ppc970 et al ) seen no major problems thus far. Also, gmp,mpfr,mpc all build fine with all tests passed even on a very very old : titan-i386-SunOS5.8 $ uname -X System = SunOS Node = titan Release = 5.8 KernelID = Generic_127722-03 Machine = i86pc BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 2 titan-i386-SunOS5.8 $ psrinfo -v Status of virtual processor 0 as of: 03/12/12 11:47:00 on-line since 04/28/11 17:39:44. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. Status of virtual processor 1 as of: 03/12/12 11:47:00 on-line since 04/28/11 17:39:48. The i386 processor operates at 400 MHz, and has an i387 compatible floating point processor. titan-i386-SunOS5.8 $ cat /etc/release Solaris 8 2/02 s28x_u7wos_08a INTEL Copyright 2002 Sun Microsystems, Inc. All Rights Reserved. Assembled 18 December 2001 So I have not seen a gmp mpfr or mpc issue, anywhere. HOWEVER, I do use the very latest revs of mpfr,gmp and mpc. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: GCC 4.7.0RC: Mangled names in cc1
2012/3/12 Ludovic Courtès : > Hi, > > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> Ian Lance Taylor skribis: >>> ludovic.cour...@inria.fr (Ludovic Courtès) writes: > Ian Lance Taylor skribis: > >> ludovic.cour...@inria.fr (Ludovic Courtès) writes: >> >>> However, this means that plug-ins must now be built with g++, except >>> when GCC was configured with --disable-build-poststage1-with-cxx. This >>> seems difficult to deal with, for plug-in writers. >> >> This is an unfortunate truth during our transition to building gcc with >> C++. There is going to be a period of time when the compiler may be >> built as either C or C++. The end goal is for the compiler to always be >> built with C++, but until we reach that state I think plugin writers >> will have to test. > > What about wrapping the C API in extern "C"? We eventually will want the internal APIs to be C++, so this transition will inevitably happen at some point. >>> >>> I understand the goal. However, should a C++ API be added, the C-only >>> part could still be kept extern "C". >> >> We are talking here about internal GCC functions. We are not talking >> about an actual defined API. The defined API is in plugin-api.h, and >> that remains extern "C". There is no "C-only part" of the internal API. > > Hmm is for linker plug-ins; provides > nothing more than the event mechanism. > > Symbols declared in are mangled, for instance. I’m not sure > whether is considered internal or not, but I can hardly see > what kind of plug-in could be written without using it. > >>> For 4.7.0, as Duncan Sands writes, it would be a very helpful for the >>> ABI to be independent of configuration options–i.e., either mangled or >>> unmangled symbols. >> >> That just postpones the pain to gcc 4.8.0. > > In 4.8 things will be easier: plug-ins will have to be compiled with g++. > > In 4.7, finding out whether gcc or g++ should be used is left as an > exercise to the plug-in writer, which is inconvenient at best. Well, that is what you get for having plugins without a proper plugin API ;) It's not going to change for 4.7. Anybody who is willing to attack the fundamental plugin issue is advised to develop a separate, stable (and thus forward-looking) C plugin interface (and make all other symbols hidden again). Richard. > Thanks, > Ludo’.
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On Mon, 12 Mar 2012, NightStrike wrote: > On Mon, Mar 12, 2012 at 5:59 AM, Richard Guenther wrote: > > On Wed, 7 Mar 2012, NightStrike wrote: > > > >> On Fri, Mar 2, 2012 at 8:44 AM, Richard Guenther wrote: > >> > > >> > GCC 4.7.0 Release Candidate available from gcc.gnu.org > >> > > >> > The first release candidate for GCC 4.7.0 is available from > >> > > >> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 > >> > > >> > and shortly its mirrors. It has been generated from SVN revision 184777. > >> > > >> > I have so far bootstrapped and tested the release candidate on > >> > x86_64-linux. Please test it and report any issues to bugzilla. > >> > > >> > If all goes well, I'd like to release 4.7.0 in about three weeks. > >> > >> > >> Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step > >> with the current version of mpfr version 3.1.0, out since last > >> October, and mpc, version 0.9, out since Feb of 2011. I'm guessing > >> the sources moved or something. > >> > >> For instance, just to get the configure step to pass, I had to change > >> the last line of the configure step in the generated Makefile from > >> this: > >> > >> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp > >> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs > >> --with-mpfr-include=$$s/mpfr > >> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs > >> > >> to this: > >> > >> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp > >> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs > >> --with-mpfr-include=$$s/mpfr/src > >> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs > >> > >> > >> The key section is adding /src on the end of > >> --with-mpfr-include=$$s/mpfr/src > >> > >> > >> That gets the build further, but it still doesn't work. > >> > >> This same problem affects 4.6. > > > > The suggested versions of the packages in doc/install.texi are > > older than the ones you tried. > > > > Feel free to propose a patch for trunk, changing the recommended > > versions there. > > > > Richard. > > Ok. But does that mean that to fix configure, we have to increase the > minimum version of mpfr? Well, or somehow support and detect both variants for in-tree builds. IMHO we should exactly allow a _single_ version of the libraries for in-tree builds (well, maybe allow patchlevel changes). And we should document these versions as recommended. Richard.
Re: GCC 4.7.0RC: Mangled names in cc1
On Mon, Mar 12, 2012 at 3:56 AM, Ludovic Courtès wrote: > Symbols declared in are mangled, for instance. I’m not sure > whether is considered internal or not, but I can hardly see > what kind of plug-in could be written without using it. tree.h is internal. -- Gaby
Re: GCC 4.7.0RC: Mangled names in cc1
On Mon, Mar 12, 2012 at 7:10 AM, Richard Guenther wrote: >> In 4.7, finding out whether gcc or g++ should be used is left as an >> exercise to the plug-in writer, which is inconvenient at best. > > Well, that is what you get for having plugins without a proper plugin API ;) > It's not going to change for 4.7. Anybody who is willing to attack the > fundamental plugin issue is advised to develop a separate, stable > (and thus forward-looking) C plugin interface (and make all other > symbols hidden again). I thought people who were using the plugins in its current form understood that things could change from release to release. -- Gaby
Re: Memory Model
On 03/10/2012 09:17 AM, Joe Gottman wrote: According to the news on the front page, the C++11 memory model has been added to gcc. But C++11 status page (http://gcc.gnu.org/projects/cxx0x.html) says that it hasn't. Is this an oversight? Atomic support with memory model parameters have been added, but complete support is not quite there yet. A full optimization audit has not been performed, so it is possible to introduce data races which were not there before. Bitfields operations do not yet conform either. That said, any one who encounters cases where those memory model non-compliances occur should open a bugzilla so we can make sure we have them covered in 4.8. Andrew
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On Mon, Mar 12, 2012 at 8:05 AM, Dennis Clarke wrote: > >> On Mon, Mar 12, 2012 at 5:59 AM, Richard Guenther wrote: >>> On Wed, 7 Mar 2012, NightStrike wrote: >>> On Fri, Mar 2, 2012 at 8:44 AM, Richard Guenther wrote: > > GCC 4.7.0 Release Candidate available from gcc.gnu.org > > The first release candidate for GCC 4.7.0 is available from > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 > > and shortly its mirrors. It has been generated from SVN revision 184777. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux. Please test it and report any issues to bugzilla. > > If all goes well, I'd like to release 4.7.0 in about three weeks. Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step with the current version of mpfr version 3.1.0, out since last October, and mpc, version 0.9, out since Feb of 2011. I'm guessing the sources moved or something. For instance, just to get the configure step to pass, I had to change the last line of the configure step in the generated Makefile from this: --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs --with-mpfr-include=$$s/mpfr --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs to this: --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs --with-mpfr-include=$$s/mpfr/src --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs The key section is adding /src on the end of --with-mpfr-include=$$s/mpfr/src That gets the build further, but it still doesn't work. This same problem affects 4.6. >>> >>> The suggested versions of the packages in doc/install.texi are >>> older than the ones you tried. >>> >>> Feel free to propose a patch for trunk, changing the recommended >>> versions there. >>> >>> Richard. >> >> Ok. But does that mean that to fix configure, we have to increase the >> minimum version of mpfr? > > seen no major problems thus far. Also, gmp,mpfr,mpc all build fine > with all tests passed even on a very very old : Are you building in tree?
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On Mon, Mar 12, 2012 at 8:25 AM, Richard Guenther wrote: > On Mon, 12 Mar 2012, NightStrike wrote: > >> On Mon, Mar 12, 2012 at 5:59 AM, Richard Guenther wrote: >> > On Wed, 7 Mar 2012, NightStrike wrote: >> > >> >> On Fri, Mar 2, 2012 at 8:44 AM, Richard Guenther >> >> wrote: >> >> > >> >> > GCC 4.7.0 Release Candidate available from gcc.gnu.org >> >> > >> >> > The first release candidate for GCC 4.7.0 is available from >> >> > >> >> > ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 >> >> > >> >> > and shortly its mirrors. It has been generated from SVN revision >> >> > 184777. >> >> > >> >> > I have so far bootstrapped and tested the release candidate on >> >> > x86_64-linux. Please test it and report any issues to bugzilla. >> >> > >> >> > If all goes well, I'd like to release 4.7.0 in about three weeks. >> >> >> >> >> >> Building gmp/mpfr/mpc in tree fails in the configure-stage1-mpc step >> >> with the current version of mpfr version 3.1.0, out since last >> >> October, and mpc, version 0.9, out since Feb of 2011. I'm guessing >> >> the sources moved or something. >> >> >> >> For instance, just to get the configure step to pass, I had to change >> >> the last line of the configure step in the generated Makefile from >> >> this: >> >> >> >> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp >> >> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs >> >> --with-mpfr-include=$$s/mpfr >> >> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs >> >> >> >> to this: >> >> >> >> --disable-shared --with-gmp-include=$$r/$(HOST_SUBDIR)/gmp >> >> --with-gmp-lib=$$r/$(HOST_SUBDIR)/gmp/.libs >> >> --with-mpfr-include=$$s/mpfr/src >> >> --with-mpfr-lib=$$r/$(HOST_SUBDIR)/mpfr/.libs >> >> >> >> >> >> The key section is adding /src on the end of >> >> --with-mpfr-include=$$s/mpfr/src >> >> >> >> >> >> That gets the build further, but it still doesn't work. >> >> >> >> This same problem affects 4.6. >> > >> > The suggested versions of the packages in doc/install.texi are >> > older than the ones you tried. >> > >> > Feel free to propose a patch for trunk, changing the recommended >> > versions there. >> > >> > Richard. >> >> Ok. But does that mean that to fix configure, we have to increase the >> minimum version of mpfr? > > Well, or somehow support and detect both variants for in-tree builds. > IMHO we should exactly allow a _single_ version of the libraries for > in-tree builds (well, maybe allow patchlevel changes). And we should > document these versions as recommended. > > Richard. There's already a patch for that on the bugzilla PR that went ignored.
[Patch,AVR]: Fix PR52488 (insane stack usage)
This patch cuts down insane stack offsets for 8-bit SP targets to a value the
involved insns can handle.
Background is that newlib generates such insane offsets (2050 bytes of stack
for a device with 128 bytes of RAM) because of extension PR51345, i.e. new
multilib variants for 8-bit SP targets.
The CFA notes still contain the original size as requested by the source so
that -Wstack-usage= will still work as intended.
The generated code will never be functional, of course, but there should never
be an ICE.
This patch is less aggressive than the patch proposed in the PR, i.e. it is
silent and does not issue an error so that newlib can still be built. If the
user wants additional sanity checking, he has to use -Wstack-usage= or similar
options.
Passed testsuite.
Ok for trunk?
Johann
PR target/52488
* config/avr/avr.c (avr_prologue_setup_frame): Cut down stack
offset (size) to a value the insns can deal with.
(expand_epilogue): Ditto.
Index: config/avr/avr.c
===
--- config/avr/avr.c (revision 185100)
+++ config/avr/avr.c (working copy)
@@ -827,7 +827,11 @@ avr_prologue_setup_frame (HOST_WIDE_INT
bool isr_p = cfun->machine->is_interrupt || cfun->machine->is_signal;
int live_seq = sequent_regs_live ();
+ HOST_WIDE_INT size_max
+= (HOST_WIDE_INT) GET_MODE_MASK (AVR_HAVE_8BIT_SP ? QImode : Pmode);
+
bool minimize = (TARGET_CALL_PROLOGUES
+ && size < size_max
&& live_seq
&& !isr_p
&& !cfun->machine->is_OS_task
@@ -933,6 +937,7 @@ avr_prologue_setup_frame (HOST_WIDE_INT
leaf function and thus X has already been saved. */
int irq_state = -1;
+ HOST_WIDE_INT size_cfa = size;
rtx fp_plus_insns, fp, my_fp;
gcc_assert (frame_pointer_needed
@@ -951,6 +956,27 @@ avr_prologue_setup_frame (HOST_WIDE_INT
my_fp = all_regs_rtx[FRAME_POINTER_REGNUM];
}
+ /* Cut down size and avoid size = 0 so that we don't run
+ into ICE like PR52488 in the remainder. */
+
+ if (size > size_max)
+{
+ /* Don't error so that insane code from newlib still compiles
+ and does not break building newlib. As PR51345 is implemented
+ now, there are multilib variants with -mtiny-stack.
+
+ If user wants sanity checks he can use -Wstack-usage=
+ or similar options.
+
+ For CFA we emit the original, non-saturated size so that
+ the generic machinery is aware of the real stack usage and
+ will print the above diagnostic as expected. */
+
+ size = size_max;
+}
+
+ size = trunc_int_for_mode (size, GET_MODE (my_fp));
+
/ Method 1: Adjust frame pointer /
start_sequence ();
@@ -975,7 +1001,7 @@ avr_prologue_setup_frame (HOST_WIDE_INT
RTX_FRAME_RELATED_P (insn) = 1;
add_reg_note (insn, REG_CFA_ADJUST_CFA,
gen_rtx_SET (VOIDmode, fp,
- plus_constant (fp, -size)));
+ plus_constant (fp, -size_cfa)));
}
/* Copy to stack pointer. Note that since we've already
@@ -1003,7 +1029,7 @@ avr_prologue_setup_frame (HOST_WIDE_INT
add_reg_note (insn, REG_CFA_ADJUST_CFA,
gen_rtx_SET (VOIDmode, stack_pointer_rtx,
plus_constant (stack_pointer_rtx,
--size)));
+-size_cfa)));
}
fp_plus_insns = get_insns ();
@@ -1026,7 +1052,7 @@ avr_prologue_setup_frame (HOST_WIDE_INT
add_reg_note (insn, REG_CFA_ADJUST_CFA,
gen_rtx_SET (VOIDmode, stack_pointer_rtx,
plus_constant (stack_pointer_rtx,
--size)));
+-size_cfa)));
if (frame_pointer_needed)
{
insn = emit_move_insn (fp, stack_pointer_rtx);
@@ -1048,7 +1074,7 @@ avr_prologue_setup_frame (HOST_WIDE_INT
emit_insn (fp_plus_insns);
}
- cfun->machine->stack_usage += size;
+ cfun->machine->stack_usage += size_cfa;
} /* !minimize && size != 0 */
} /* !minimize */
}
@@ -1261,6 +1287,7 @@ expand_epilogue (bool sibcall_p)
int irq_state = -1;
rtx fp, my_fp;
rtx fp_plus_insns;
+ HOST_WIDE_INT size_max;
gcc_assert (fr
regrename creates invalid insn
On m68k, int % CONST is expanded to contain this insn:
(insn 6 5 7 3 (parallel [
(set (reg:SI 35)
(truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg/v:SI 33
[ a ]))
(const_int -2004318071 [0x8889]))
(const_int 32 [0x20]
(clobber (reg:SI 36))
]) mulsl.c:4 -1
(nil))
which correspondents to this pattern:
(define_insn "const_smulsi3_highpart"
[(set (match_operand:SI 0 "register_operand" "=d")
(truncate:SI
(lshiftrt:DI
(mult:DI (sign_extend:DI (match_operand:SI 2 "register_operand" "1"))
(match_operand:DI 3 "const_sint32_operand" "n"))
(const_int 32
(clobber (match_operand:SI 1 "register_operand" "=d"))]
"TARGET_68020 && !TUNE_68060 && !TARGET_COLDFIRE"
"muls%.l %3,%0:%1")
When regrename runs it turns it into this:
(insn 6 27 7 2 (parallel [
(set (reg:SI 1 %d1 [35])
(truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg:SI 1
%d1 [36]))
(const_int -2004318071 [0x8889]))
(const_int 32 [0x20]
(clobber (reg:SI 1 %d1 [36]))
]) mulsl.c:4 192 {const_smulsi3_highpart}
(expr_list:REG_UNUSED (reg:SI 1 %d1 [36])
(nil)))
Note that both output operands are allocated to the same register (which
generates a muls.l producing undefined results). Is this transformation
actually valid? I can stop regrename from doing this by marking operand
0 as earlyclobber, but the insn doesn't actually write the outputs
before reading the inputs, the issue is the dependency between the
outputs.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
Re: fine grained control over testsuite
Dennis Clarke writes: > Q: is there a way to prevent a test timing out ? > > I see a lot of this sort of thing : > > Running /opt/bw/src/gcc-4.5.3/gcc/testsuite/gcc.c-torture/compile/compile.exp > ... > WARNING: program timed out. > FAIL: gcc.c-torture/compile/pr46534.c -O0 (test for excess errors) > WARNING: program timed out. > FAIL: gcc.c-torture/compile/pr46534.c -O1 (test for excess errors) > WARNING: program timed out. > FAIL: gcc.c-torture/compile/pr46534.c -O2 (test for excess errors) > WARNING: program timed out. > FAIL: gcc.c-torture/compile/pr46534.c -O3 -fomit-frame-pointer (test for > excess errors) > WARNING: program timed out. > . > . > . > > Somewhat annoying as I am in no particular hurry. :-) You could get a faster computer. Or you can edit gcc/site.exp in your build directory to set tool_timeout to a large value. The number is in seconds, and the default is 300. Ian
Re: regrename creates invalid insn
Andreas Schwab writes:
> When regrename runs it turns it into this:
>
> (insn 6 27 7 2 (parallel [
> (set (reg:SI 1 %d1 [35])
> (truncate:SI (lshiftrt:DI (mult:DI (sign_extend:DI (reg:SI 1
> %d1 [36]))
> (const_int -2004318071 [0x8889]))
> (const_int 32 [0x20]
> (clobber (reg:SI 1 %d1 [36]))
> ]) mulsl.c:4 192 {const_smulsi3_highpart}
> (expr_list:REG_UNUSED (reg:SI 1 %d1 [36])
> (nil)))
>
> Note that both output operands are allocated to the same register (which
> generates a muls.l producing undefined results). Is this transformation
> actually valid? I can stop regrename from doing this by marking operand
> 0 as earlyclobber, but the insn doesn't actually write the outputs
> before reading the inputs, the issue is the dependency between the
> outputs.
I assume there were two different hard register numbers before
regrename. That does not look like a valid transformation to me.
But it also looks like the pattern should use a match_scratch.
Ian
Re: regrename creates invalid insn
Ian Lance Taylor writes: > But it also looks like the pattern should use a match_scratch. It is also used as input in operand 2. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: regrename creates invalid insn
Andreas Schwab writes: > Ian Lance Taylor writes: > >> But it also looks like the pattern should use a match_scratch. > > It is also used as input in operand 2. Sorry, I missed that. This still seems like a bug in regrename to me, but it also seems like an unusual case, so it is less surprising that it hasn't been seen before. Ian
Re: regrename creates invalid insn
Ian Lance Taylor writes: > Andreas Schwab writes: > >> Ian Lance Taylor writes: >> >>> But it also looks like the pattern should use a match_scratch. >> >> It is also used as input in operand 2. > > Sorry, I missed that. That appears not to be an issue actually, there is already one use of match_scratch together with a matching constraint in *cmpdi_internal. But then, using match_scratch instead of match_operand doesn't really fix the bug either (it only helps a simplified test case, but not the original one). > This still seems like a bug in regrename to me, but it also seems like > an unusual case, so it is less surprising that it hasn't been seen > before. Since regrename is only auto-enabled with -funroll-loops it is probably not much tested anyway. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Memory Model
On 3/12/2012 8:44 AM, Andrew MacLeod wrote: On 03/10/2012 09:17 AM, Joe Gottman wrote: According to the news on the front page, the C++11 memory model has been added to gcc. But C++11 status page (http://gcc.gnu.org/projects/cxx0x.html) says that it hasn't. Is this an oversight? Atomic support with memory model parameters have been added, but complete support is not quite there yet. A full optimization audit has not been performed, so it is possible to introduce data races which were not there before. Bitfields operations do not yet conform either. That said, any one who encounters cases where those memory model non-compliances occur should open a bugzilla so we can make sure we have them covered in 4.8. OK. Does it say anywhere on the website exactly what can and can't be done with respect to the memory model? Joe Gottman
Re: regrename creates invalid insn
Andreas Schwab writes: > Ian Lance Taylor writes: > >> Andreas Schwab writes: >> >>> Ian Lance Taylor writes: >>> But it also looks like the pattern should use a match_scratch. >>> >>> It is also used as input in operand 2. >> >> Sorry, I missed that. > > That appears not to be an issue actually, there is already one use of > match_scratch together with a matching constraint in *cmpdi_internal. > But then, using match_scratch instead of match_operand doesn't really > fix the bug either (it only helps a simplified test case, but not the > original one). It doesn't actually change anything (I was confused because 4.7/4.8 no longer generates the overlapping output for the simplified testcase). Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Memory Model
On 3/12/12, Joe Gottman wrote: > On 3/12/2012 8:44 AM, Andrew MacLeod wrote: > > On 03/10/2012 09:17 AM, Joe Gottman wrote: > > > According to the news on the front page, the C++11 > > > memory model has been added to gcc. But C++11 status page > > > (http://gcc.gnu.org/projects/cxx0x.html) says that it hasn't. > > > Is this an oversight? > > > > Atomic support with memory model parameters have been added, but > > complete support is not quite there yet. A full optimization > > audit has not been performed, so it is possible to introduce > > data races which were not there before. Bitfields operations > > do not yet conform either. > > > > That said, any one who encounters cases where those memory > > model non-compliances occur should open a bugzilla so we can > > make sure we have them covered in 4.8. > > OK. Does it say anywhere on the website exactly what can and > can't be done with respect to the memory model? We cannot really know until after the optimization audit has been completed. It might be helpful to say the model is correct at some maximum optimization level, probably -O0 or -O1. -- Lawrence Crowl
