Re: GNU MPC 1.0 release candidate
Test on secondary gcc platform i686-w64-mingw32: ... GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: i686-w64-mingw32-gcc GCC: yes GCC version: 4.7.2 PASS: tget_version.exe === All 64 tests passed === Regards, Cauchy On Sat, Jul 7, 2012 at 11:13 PM, Andreas Enge wrote: > > We are pleased to announce the immediate availability of the first release > candidate for GNU MPC 1.0 at >http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz >sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 > > Reports on successful installations and potential problems are very > welcome; > please include the configuration triple of your platform, and the gcc, gmp > and mpfr versions used (these are output at the end of 'make check'). > > The status of successful and failed builds can be seen at >http://www.multiprecision.org/index.php?prog=mpc&page=platforms > > In particular, we need to compile on the primary and secondary gcc > platforms > before the release. > > Thank you very much for your help, > > Andreas
Re: GNU MPC 1.0 release candidate
Test on x86_64-apple-darwin10 GMP: include 5.0.4, lib 5.0.4 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: gcc GCC: yes GCC version: 4.8.0 PASS: tget_version === All 64 tests passed === Dominique
Re: GNU MPC 1.0 release candidate
On 07.07.12 17:13, Andreas Enge wrote: We are pleased to announce the immediate availability of the first release candidate for GNU MPC 1.0 at http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 Reports on successful installations and potential problems are very welcome; please include the configuration triple of your platform, and the gcc, gmp and mpfr versions used (these are output at the end of 'make check'). The status of successful and failed builds can be seen at http://www.multiprecision.org/index.php?prog=mpc&page=platforms In particular, we need to compile on the primary and secondary gcc platforms before the release. Thank you very much for your help, - powerpc64-unknown-freebsd10.0 - powerpc-unknown-freebsd10.0 - x86_64-unknown-freebsd10.0 GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.0-p10, lib 3.1.0-p10 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: gcc GCC: yes GCC version: 4.2.1 PASS: tget_version === All 64 tests passed === All above ok. Andreas
Re: Endless "declared 'static' but never defined" warnings with stage 2 & 3 compilers
On 2012-07-01, at 12:53 PM, Vincent Rivière wrote: > On 01/07/2012 16:16, t-rexky wrote: >> I discovered that if I rebuild stage 3 with BOOT_CFLAGS="-g -O0", the >> warnings in stage 3 compiler all disappear! > > This is extremely wierd! > > So it looks like something is affected by the optimization level. Usually, it > is an uninitialized variable, buffer overflow, strict aliasing issue, or > maybe a GCC bug... > > Since it is unlikely that this specific bug is in the standard GCC sources > (other people would have noticed), maybe it could be somewhere in the C > sources added for your NeXT configuration? I am also certain that this is somehow related to my configuration so I reviewed my target config files once again but there was nothing obvious staring back at me. At one point I thought that there was an issue with the TARGET_ASM_SELECT_SECTION function that I pulled in from gcc-3.2.3, so I completely rewrote it using the Darwin version from gcc-4.2.4 (conveniently Darwin is almost identical to NEXTSTEP minus some new features like weak support, coalesced sections, etc). I spent the last week fiddling with this due to the length of the bootstrap process on the 68040, but unfortunately to no avail... I might have no choice but to get a newer gdb version going if I do not find anything else... t-rexky
Re: GNU MPC 1.0 release candidate
Test on x86_64-w64-mingw32 : GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: i686-w64-mingw32-gcc -m64 GCC: yes GCC version: 4.7.2 PASS: tget_version.exe === All 64 tests passed === On Sat, Jul 7, 2012 at 11:13 PM, Andreas Enge wrote: > We are pleased to announce the immediate availability of the first release > candidate for GNU MPC 1.0 at >http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz >sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 > > Reports on successful installations and potential problems are very welcome; > please include the configuration triple of your platform, and the gcc, gmp > and mpfr versions used (these are output at the end of 'make check'). > > The status of successful and failed builds can be seen at >http://www.multiprecision.org/index.php?prog=mpc&page=platforms > > In particular, we need to compile on the primary and secondary gcc platforms > before the release. > > Thank you very much for your help, > > Andreas
Random crash
My C++ application which uses Qt and libsigc++ libraries is stable if all 3 components are compiled with GCC 4.4.7 If my app is compiled with GCC 4.7.1 it crashes in random time and place inside Qt library as detected by GDB. I tried to run app with Valgrind, but didn't have crash yet. How can I find reason for such crash? Thanks for help.
Re: Random crash
On 8 July 2012 18:43, wbrana wrote: > My C++ application which uses Qt and libsigc++ libraries is stable if > all 3 components are compiled with GCC 4.4.7 > If my app is compiled with GCC 4.7.1 it crashes in random time and > place inside Qt library as detected by GDB. > I tried to run app with Valgrind, but didn't have crash yet. > How can I find reason for such crash? > Thanks for help. This message is not appropriate for the mailing list gcc@gcc.gnu.org, which is about the development of GCC itself. It would be appropriate for gcc-h...@gcc.gnu.org. Please take any followups to gcc-help. Thanks. If the crash is truly random, not repeatable, then it could be due to a bug in your program that result in memory corruption, or even due to hardware problems, but you haven't provided nearly enough information (not even what you mean by "random" or "crash") so it's not possible for anyone to answer accurately. If you ask on the gcc-help list then please try to provide enough information for someone to try and help.
Re: GNU MPC 1.0 release candidate
On 08.07.12 12:32, Andreas Tobler wrote: On 07.07.12 17:13, Andreas Enge wrote: We are pleased to announce the immediate availability of the first release candidate for GNU MPC 1.0 at http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 Reports on successful installations and potential problems are very welcome; please include the configuration triple of your platform, and the gcc, gmp and mpfr versions used (these are output at the end of 'make check'). The status of successful and failed builds can be seen at http://www.multiprecision.org/index.php?prog=mpc&page=platforms In particular, we need to compile on the primary and secondary gcc platforms before the release. Thank you very much for your help, - powerpc64-unknown-freebsd10.0 - powerpc-unknown-freebsd10.0 - x86_64-unknown-freebsd10.0 GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.0-p10, lib 3.1.0-p10 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: gcc GCC: yes GCC version: 4.2.1 PASS: tget_version === All 64 tests passed === All above ok. I forgot this one: i386-unknown-freebsd10.0 also ok. Andreas
problems in interaction between peephole on CALL_INSN and final_scan_insn
When a peephole is recognized, the first insn in the group is replaced by a
pseudo insn that contains all the referenced operands in the TEMPLATE and sets
an INSN_CODE to indicate which peephole matched.
This is all well and good, except that if the peephole involves a CALL_INSN,
final_scan_insn() will invoke call_from_call_insn() to try and get the call
RTL. But if the peephole is in fact some kind of a tail call, we no longer
have a call expression to be found and end up asserting in
call_from_call_insn().
I think I can work around this by switching to a define_peephole2 converting
the call & return into an unspec, or maybe by doing a match tthat grabs the
whole call as an operand instead of just the function address.
I'm not sure if the correct fix to this involves changing the way genpeep.c
works or changing call_from_call_insn to be more forgiving - either one seems
really difficult unless there's existing code that transmutes top-level RTL
among CALL_INSN, JUMP_INSN, etc already...
Just in case I'm doing something stupid, here's my peephole
(define_peephole
[
(parallel [(set (reg:SI RV_REGNUM)
(call (match_operand:SI 0 "memory_operand" "")
(match_operand 1 "" "")))
(clobber (reg:SI LR_REGNUM))])
(parallel [(use (match_operand 2 "ieu_operand" "rm"))
(return)])
]
"!final_sequence"
{
if (CONSTANT_P (operands[0]))
return "jmp\t%0\; mov\tr0,%2";
else
return "ret\t%0\; mov\tr0,%2";
}
[(set_attr "type" "call")]
)
Re: problems in interaction between peephole on CALL_INSN and final_scan_insn
On Sun, Jul 8, 2012 at 2:23 PM, Alan Lehotsky wrote:
> When a peephole is recognized, the first insn in the group is replaced by a
> pseudo insn that contains all the referenced operands in the TEMPLATE and
> sets an INSN_CODE to indicate which peephole matched.
>
> This is all well and good, except that if the peephole involves a CALL_INSN,
> final_scan_insn() will invoke call_from_call_insn() to try and get the call
> RTL. But if the peephole is in fact some kind of a tail call, we no longer
> have a call expression to be found and end up asserting in
> call_from_call_insn().
Simple answer don't use peephole optimization to perform the tail call
optimization. There are better ways of performing that optimization.
Thanks,
Andrew
>
> I think I can work around this by switching to a define_peephole2 converting
> the call & return into an unspec, or maybe by doing a match tthat grabs the
> whole call as an operand instead of just the function address.
>
> I'm not sure if the correct fix to this involves changing the way genpeep.c
> works or changing call_from_call_insn to be more forgiving - either one seems
> really difficult unless there's existing code that transmutes top-level RTL
> among CALL_INSN, JUMP_INSN, etc already...
>
>
> Just in case I'm doing something stupid, here's my peephole
>
> (define_peephole
> [
> (parallel [(set (reg:SI RV_REGNUM)
> (call (match_operand:SI 0 "memory_operand" "")
> (match_operand 1 "" "")))
> (clobber (reg:SI LR_REGNUM))])
> (parallel [(use (match_operand 2 "ieu_operand" "rm"))
> (return)])
> ]
> "!final_sequence"
>
> {
> if (CONSTANT_P (operands[0]))
> return "jmp\t%0\; mov\tr0,%2";
> else
> return "ret\t%0\; mov\tr0,%2";
> }
>
> [(set_attr "type" "call")]
> )
>
Re: problems in interaction between peephole on CALL_INSN and final_scan_insn
I'm certain there are better ways; can you be more specific though? Or are you just talking about defining a sibcall_epilogue pattern? On Jul 8, 2012, at 5:26 PM, Andrew Pinski wrote: > On Sun, Jul 8, 2012 at 2:23 PM, Alan Lehotsky wrote: >> When a peephole is recognized, the first insn in the group is replaced by a >> pseudo insn that contains all the referenced operands in the TEMPLATE and >> sets an INSN_CODE to indicate which peephole matched. >> >> This is all well and good, except that if the peephole involves a CALL_INSN, >> final_scan_insn() will invoke call_from_call_insn() to try and get the call >> RTL. But if the peephole is in fact some kind of a tail call, we no longer >> have a call expression to be found and end up asserting in >> call_from_call_insn(). > > > Simple answer don't use peephole optimization to perform the tail call > optimization. There are better ways of performing that optimization. > > Thanks, > Andrew
gcc-4.8-20120708 is now available
Snapshot gcc-4.8-20120708 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20120708/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 189361 You'll find: gcc-4.8-20120708.tar.bz2 Complete GCC MD5=564bc399a669cffdcd4567e420d50657 SHA1=140019ddeb5d6c5253d117119009dda2fbffca86 Diffs from 4.8-20120701 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 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.
Re: [Mpc-discuss] GNU MPC 1.0 release candidate
- Original Message - From: "Andreas Enge" To: ; Sent: Sunday, July 08, 2012 1:13 AM Subject: [Mpc-discuss] GNU MPC 1.0 release candidate We are pleased to announce the immediate availability of the first release candidate for GNU MPC 1.0 at http://www.multiprecision.org/mpc/download/mpc-1.0.0rc1.tar.gz sha1sum 9acc8a54ba4ecd0ccf172c0d07fcc218220e79a3 Reports on successful installations and potential problems are very welcome; please include the configuration triple of your platform, and the gcc, gmp and mpfr versions used (these are output at the end of 'make check'). Builds fine ands passes all 64 tests for me on i686-pc-mingw32, though I've tried only static builds. 32-bit: GMP: include 5.0.5, lib 5.0.5 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: gcc GCC: yes GCC version: 4.5.2 64 bit: MPIR: include 2.5.1, lib 2.5.1 MPFR: include 3.1.1, lib 3.1.1 MPC: include 1.0.0rc1, lib 1.0.0rc1 C compiler: x86_64-w64-mingw32-gcc GCC: yes GCC version: 4.7.0 Math::MPC (perl) no longer builds against this library because of undefined references to 'mpc_mul_2exp' and 'mpc_div_2exp'. Looks like those functions are no longer present - which doesn't bother me greatly. Is there a list from which one can easily find *all* alterations that have been made to the API ? Cheers, Rob
