Re: gcc trunk

Hi Murali, On Thu, 26 Oct 2006, Murali Vemulapati wrote: > what is the release number for gcc trunk (mainline)? currently there > are two branches 4.2.0 and 4.3.0 which are accepting patches. we tried to provide this information on our main web page at http://gcc.gnu.org. If this does not relay

Re: gcc trunk

Gerald Pfeifer wrote: Hi Murali, On Thu, 26 Oct 2006, Murali Vemulapati wrote: what is the release number for gcc trunk (mainline)? currently there are two branches 4.2.0 and 4.3.0 which are accepting patches. we tried to provide this information on our main web page at http://gcc.gnu.org. If

Re: gcc trunk

On Oct 26, 2006, at 7:10 PM, Murali Vemulapati wrote: what is the release number for gcc trunk (mainline)? $ cat gcc/BASE-VER will always show you the correct information, presently it says: 4.3.0

Re: gcc trunk

On Thu, 26 Oct 2006, Brooks Moses wrote: > I would say, on looking at it, that the order of items under "Status" is > slightly confusing; it seems to me that "Active Development" ought go > next to "Next Release Series". That's a good point. >From a user perspective, how about Current (4.1)

RE: gcc trunk

On 02 November 2006 13:12, Gerald Pfeifer wrote: > On Thu, 26 Oct 2006, Brooks Moses wrote: >> I would say, on looking at it, that the order of items under "Status" is >> slightly confusing; it seems to me that "Active Development" ought go >> next to "Next Release Series". > > That's a good poin

RE: gcc trunk

On Thu, 2 Nov 2006, Dave Korn wrote: >> From a user perspective, how about >> >> Current (4.1) >> Previous (4.0) >> Next (4.2) >> Active development (4.3) > Let's be user-centric. Us developers can be expected to cope. Okay. ;-) Nobody else chimed in, so I went ahead and committed the p

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

>Is there someone who an dig into the commit below >and try to find out how the author field was incorrectly set? That gets set when the local commit is done, before pushing it to the server. I don't think there's any way to find out how/why that happened after the fact. You did author the commit

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道: Is there someone who an dig into the commit below and try to find out how the author field was incorrectly set? That gets set when the local commit is done, before pushing it to the server. I don't think there's any way to find out how/why that ha

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote: > > 在 2021-06-16 23:22, Jonathan Wakely via Gcc 写道: > >> Is there someone who an dig into the commit below > >> and try to find out how the author field was incorrectly set? > > > > That gets set when the local commit is done, before pushing it to the

Re: GCC trunk commit a325bdd195ee96f826b208c3afb9bed2ec077e12

On 6/16/21 1:32 PM, Uros Bizjak wrote: > On Wed, Jun 16, 2021 at 6:08 PM Liu Hao wrote: >> It looks like Uroš was on 00d07ec6e12, committed his changes mistakenly with >> `git commit --amend` >> (which changed the commit message but did not reset the author), then >> rebased the modified commit

Re: gcc trunk vs python

Hello Jack, I has been almost a week since you mailed your question. I hope my answer is still relevant. Jack Howarth wrote: Has anyone tried building python 2.4.3 using gcc trunk? The current gcc 4.2 seems to introduce a new regression in the Python testsuite... test_builtin test test_bu

Re: gcc trunk vs python

Michael, If I build python 2.4.3 with the default compiler flags under gcc trunk on MacOS X 10.4.7, I get the following... Python 2.4.3 (#1, Aug 23 2006, 17:39:08) [GCC 4.2.0 20060822 (experimental)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import s

Re: gcc trunk vs python

> So your analysis appears to be correct. Even more interesting is > that if I build python 2.4.3 with Apple's gcc from Xcode 2.3, the > correct results are obtained without the need to resort to the > -fwrapv flag. So either we have a regression in gcc trunk or > Apple has a patch in their branch

Re: gcc trunk vs python

On Aug 23, 2006, at 3:27 PM, Jack Howarth wrote: The only difference I can see between the builds with gcc trunk and Apple's gcc is that I have to remove the -Wno-long-double -no-cpp- precomp flags the build with gcc trunk (because they don't exist). My only comment would be to remove -Wno-lo

Re: gcc trunk vs python

Jack Howarth wrote: import sys divmod(-sys.maxint-1, -1) (0, -2147483648) If I add the -fwrapv flag to BASECFLAGS in the Makefile, I get... (2147483648L, 0L) So your analysis appears to be correct. Even more interesting is that if I build python 2.4.3 with Apple's gcc fro

Re: gcc trunk vs python

Sorry for the formatting weirdness. I should be more careful with Thunderbird's auto-conversion to plain text. Here is the correct version: Jack Howarth wrote: import sys divmod(-sys.maxint-1, -1) (0, -2147483648) If I add the -fwrapv flag to BASECFLAGS in the Makefile, I get...

Re: gcc trunk vs python

Michael, I submitted a bug report to the python developers. Do you have a suggestion on how... /* (-sys.maxint-1)/-1 is the only overflow case. */ if (y == -1 && x < 0 && x == -x) return DIVMOD_OVERFLOW; ...should be reworked? Since I am tickling the bug at the

Re: gcc trunk vs python

x < 0 && x == -x That is the issue right there really, doing x == -x will never be true because -x will overflow for INT_MIN. Doing "((unsigned)x) == -(unsigned)x" should fix the issue. Note this is unrelated to Darwin or any processor really too. -- Pinski

Re: gcc trunk vs python

Andrew, Thanks. The change... --- Python-2.4.3/Objects/intobject.c.org2006-08-23 23:49:33.0 -0400 +++ Python-2.4.3/Objects/intobject.c2006-08-23 23:52:01.0 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-sys.maxint-1)/-1 is the

Re: gcc trunk vs python

Jack Howarth wrote: Andrew, Thanks. The change... --- Python-2.4.3/Objects/intobject.c.org2006-08-23 23:49:33.0 -0400 +++ Python-2.4.3/Objects/intobject.c2006-08-23 23:52:01.0 -0400 @@ -479,7 +479,7 @@ return DIVMOD_ERROR; } /* (-s

Re: gcc trunk vs python

Paolo Bonzini wrote: Jack Howarth wrote: + if (y == -1 && x < 0 && ((unsigned)x) == -(unsigned)x) return DIVMOD_OVERFLOW; or just a much clearer if (y == -1 && x == INT_MIN) return DIVMOD_OVERFLOW; (possibly with a #include at the top). Nit picking - "x" i

Re: gcc trunk vs python

Would any of the gcc developers care to drop by the python-dev mailing list and give the author of python an answer? http://mail.python.org/pipermail/python-dev/2006-August/068482.html On 8/26/06, Jack Howarth wrote: >

Re: gcc trunk vs python

Jack Howarth wrote: Would any of the gcc developers care to drop by the python-dev mailing list and give the author of python an answer? http://mail.python.org/pipermail/python-dev/2006-August/068482.html *Guido van Rossum wrote: * I'm not sure I follow why this isn't considered a regre

Re: gcc trunk vs python

Michael Veksler wrote: First, you can always use -fwarpv and retail old behavior. Any code that ^^ -fwrapv

Re: gcc trunk vs python

On 8/26/06, Michael Veksler <[EMAIL PROTECTED]> wrote: Jack Howarth wrote: >Would any of the gcc developers care to drop by the python-dev > mailing list and give the author of python an answer? > > http://mail.python.org/pipermail/python-dev/2006-August/068482.html > > *Guido van Rossum wrot

Re: gcc trunk vs python

"Guido van Rossum" <[EMAIL PROTECTED]> writes: > I know I cannot win an argument with the GCC developers but I can't > help wondering if they've gone bonkers. They may get Python 2.5 fixed, > but what about 2.4? 2.3? This code has been there for a long time. > > It would be better if one had to e

Re: gcc trunk vs python

On 27 Aug 2006 09:05:47 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: "Guido van Rossum" <[EMAIL PROTECTED]> writes: > I know I cannot win an argument with the GCC developers but I can't > help wondering if they've gone bonkers. They may get Python 2.5 fixed, > but what about 2.4? 2.3? This

Re: gcc trunk vs python

"Guido van Rossum" <[EMAIL PROTECTED]> writes: [...] | > In general I think I personally am on the very conservative edge of | > gcc developers, in that I am generally opposed to breaking existing | > code. But this particular optimization will let us do a much better | > job on very simple loop

Re: gcc trunk vs python

Guido van Rossum wrote: It has calmed me down. But I hope that the future quality of the arguments defending the feature is better than Michael Veksler's attempt. Thanks for responding in person. Sorry, next time I'll find a better example. Gosh, who would think that a benign example, would st

Re: gcc trunk vs python

On 8/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: ... I have not received reports about bugs in the offending code when compiled with other compilers. I do know at least one another compiler that does this, and at least one significant project (which is actually quite a bit larger than Py

Re: GCC trunk frozen for the tuples merge

On Sun, 27 Jul 2008, Richard Guenther wrote: > The trunk is frozen now until after the merge of the tuples branch > which will happen tomorrow, Monday Jul 28th. Unfreezing of the > trunk will be annonced after the fact. The merge is done and the trunk is open again under the usual stage1 rules.

Re: GCC trunk frozen for the tuples merge

Richard, Is there any information on what sort of performance improvements we might see from the tuples merge? Or would those require additional merges like graphite? Jack On Mon, Jul 28, 2008 at 04:42:26PM +0200, Richard Guenther wrote: > On Sun, 27 Jul 2008, Richard Guenther wrot

Re: GCC trunk frozen for the tuples merge

On Mon, 28 Jul 2008, Jack Howarth wrote: > Richard, >Is there any information on what sort of performance improvements > we might see from the tuples merge? Or would those require additional > merges like graphite? The tuples is supposed to reduce the memory footprint of our tree IL and as a

Re: GCC trunk frozen for the tuples merge

Richard, Thanks for the clarification. So we ought to see some improvements in the compile time of the polyhedron benchmarks by tomorrow... http://users.physik.fu-berlin.de/~tburnus/gcc-trunk/benchmark/ The graphite merge should provide some performance improvement regarding loop optimization

Re: GCC trunk frozen for the tuples merge

> The merge is done and the trunk is open again under the usual > stage1 rules. Don't forget to update svn.html. ;-) Cheers, Ben

Re: gcc trunk build failure on i686 darwin9

> Is anyone else seeing the following build failure on i686 Darwin9? Yes, on both ppc and i686 Darwin9. Dominique

Re: gcc trunk build failure on i686 darwin9

Dominique, Can you try to identify the regression (I'm at work today)? It should be somewhere between r139740 and r139791. Jack On Sat, Aug 30, 2008 at 10:21:49AM +0200, Dominique Dhumieres wrote: > > Is anyone else seeing the following build failure on i686 Darw

Re: gcc trunk build failure on i686 darwin9

> should be somewhere between r139740 and r139791. I have a slightly narrower range: r139753 worked with a clean bootstrap. Then incremental updates worked for r139766, 768, and 786. r139791 failed with a clean bootstrap up to 801 (incremental updates). Now the strange thing is that I reverted

Re: gcc trunk build failure on i686 darwin9

I have done a clean bootstrap for r139780 and it failed. So the fork is between r139753 (working) and r139780 (broken). I have also understood why I did not see the failures for the incremental updates: they did not rebuild libstdc++-v3 where the failure occurs. Dominique

Re: gcc trunk build failure on i686 darwin9

>From broken r139780, I did an incremental downgrade to r139770 (still broken) then to r139760 which seems to work (building libjava). So the window seems between r139760 and r139770. Dominique

Re: gcc trunk build failure on i686 darwin9

On Sat, Aug 30, 2008 at 09:13:03PM +0200, Dominique Dhumieres wrote: > >From broken r139780, I did an incremental downgrade to r139770 (still > broken) then to r139760 which seems to work (building libjava). > So the window seems between r139760 and r139770. > > Dominique Dominique, I am seei

Re: gcc trunk build failure on i686 darwin9

> I am seeing the same failure in r139763. I'll try r139761 next. r139761 works, and I confirm that r139763 is broken. I'll do r139762. Dominique

Re: gcc trunk build failure on i686 darwin9

r139762 seems broken. Could you fill a bug report: it's bed time for me and our mail exchange did not seem to have attracted any attention. Revision 139762 Jump to revision: Author: hubicka Date: Fri Aug 29 11:39:04 2008 UTC (35 hours, 39 minutes ago) Log Message: * doc/

Re: GCC trunk bootstrap failure on i686-w64-mingw32

> So what could be causing it? An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html has broken --disable-sjlj-exceptions. That's now fixed. -- Eric Botcazou

Re: GCC trunk bootstrap failure on i686-w64-mingw32

在 2022-10-29 20:15, Eric Botcazou 写道: So what could be causing it? An oversight in https://gcc.gnu.org/pipermail/gcc-cvs/2022-August/370830.html has broken --disable-sjlj-exceptions. That's now fixed. Thank you. Rebuilding now. -- Best regards, LIU Hao OpenPGP_signature Description: Op

Re: gcc trunk fails to build without isl/cloog

On Mon, Aug 13, 2012 at 9:01 AM, wrote: > The installation instructions seem to imply that GCC can be built without > having ISL and/or CLOOG installed, and the configure script accepts > --without-isl and --without-cloog. > > But I can't build that. Reading the installation instructions makes

Re: gcc trunk fails to build without isl/cloog

On Aug 13, 2012, at 12:42 PM, H.J. Lu wrote: > On Mon, Aug 13, 2012 at 9:01 AM, wrote: >> The installation instructions seem to imply that GCC can be built without >> having ISL and/or CLOOG installed, and the configure script accepts >> --without-isl and --without-cloog. >> >> But I can't b

Re: gcc trunk fails to build without isl/cloog

See . 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: gcc-trunk build error in OpenBSD on stage3

niXman writes: > in libiberty/config.h macro HAVE_LIMITS_H is undefined. Look in libiberty/config.log to see why HAVE_LIMITS_H is not defined. Also why HAVE_STDLIB_H is not defined. Ian

Re: gcc-trunk build error in OpenBSD on stage3

Diffs between stage2 and stage3. on configure libiberty for stage3 I see this warnings: configure:4962: checking for limits.hconfigure:4962: /home/root/gcc-build/build/gcc-trunk/./prev-gcc/xgcc-B/home/root/gcc-build/build/gcc-trunk/./prev-gcc/-B/usr/local/i686-pc-openbsd5.0/bin/-B/usr/local/i686-

Re: gcc-trunk build error in OpenBSD on stage3

> Why is this failing on your system? Up to now, I've been building GCC on a different machine (the OS wasn't installed by me). Now, I have installed OpenBSD-5.0 on the VM. > Look for uses of RPATH_ENVVAR in the top level Makefile. This line from Makefile: RPATH_ENVVAR = LD_LIBRARY_PATH LD_LIBR

Re: gcc-trunk build error in OpenBSD on stage3

niXman writes: >> Why is this failing on your system? > Up to now, I've been building GCC on a different machine (the OS > wasn't installed by me). Now, I have installed OpenBSD-5.0 on the VM. > > >> Look for uses of RPATH_ENVVAR in the top level Makefile. > This line from Makefile: > RPATH_ENVVA

Re: GCC trunk build failed on ia64: ICE in __gcov_init

Grigory Zagorodnev wrote: Hi! Build of mainline GCC on ia64-redhat-linux failed since Thu Jun 8 16:23:09 UTC 2006 (revision 114488). Last successfully built revision is 114468. I wonder if somebody sees the same. ... - Grigory This was fixed in revision 114604. -- Maxim

Re: GCC trunk failed to compile cpu2k6/dealII at x86_64

Grigory Zagorodnev wrote: GCC 4.3 revision 120799 fails to compile SPEC cpu2006/447.dealII benchmark at x86_64-redhat-linux on -O2 optimization level. Last revision know to be good is 120775. It appears that revision 120767 causes the failure http://gcc.gnu.org/viewcvs?view=rev&revision=12076

Re: gcc trunk rev. 127646 breaks bootstrap during stage 3

On 8/20/07, Thomas Veith <[EMAIL PROTECTED]> wrote: > Hi, > > when bootstrapping gcc trunk rev. 127646 with > > ./contrib/gcc_build -c "--prefix=/home/xtv > --enable-languages=c,c++,objc,fortran,obj-c++ --enable-bootstrap > --enable-decimal-float=bid --enable-checking" -d /home/xtv/gcc-devel/gcc >

Re: gcc trunk rev. 127646 breaks bootstrap during stage 3

On 8/20/07, Andrew Pinski <[EMAIL PROTECTED]> wrote: > On 8/20/07, Thomas Veith <[EMAIL PROTECTED]> wrote: > > Hi, > > > > when bootstrapping gcc trunk rev. 127646 with > > > > ./contrib/gcc_build -c "--prefix=/home/xtv > > --enable-languages=c,c++,objc,fortran,obj-c++ --enable-bootstrap > > --enab

Re: GCC trunk revision 166285 passes SPEC CPU 2000/2006

On Fri, Nov 5, 2010 at 1:43 PM, H.J. Lu wrote: > FYI, GCC trunk revision 166285 passes SPEC CPU 2000/2006. > It is the first time in a month. Ship it! Richard.

Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc

On Fri, Jan 12, 2007 at 09:30:27PM +0300, Grigory Zagorodnev wrote: > Hi! > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > higher optimization level at x86_64-redhat-linux. > > reload1.c: In function 'reload': > reload1.c:449: error: address taken, but ADDRESSABLE bit not

Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc

Hello, > > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > > higher optimization level at x86_64-redhat-linux. > > > > reload1.c: In function 'reload': > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > bad_spill_regs > > > > reload1.c:449: error: a

Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc

Hello, > > > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > > > higher optimization level at x86_64-redhat-linux. > > > > > > reload1.c: In function 'reload': > > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > > bad_spill_regs > > > > > > reload1

Re: GCC trunk revision 120704 failed to build spec cpu2k/gcc

> Hello, > > > > > GCC trunk revision 120704 failed to build SPEC cpu2000/gcc on -O1 and > > > > higher optimization level at x86_64-redhat-linux. > > > > > > > > reload1.c: In function 'reload': > > > > reload1.c:449: error: address taken, but ADDRESSABLE bit not set > > > > bad_spill_regs > >

Re: gcc-trunk bootstrap failure in libjava on i686-pc-cygwin

Rainer Emrich wrote: > shows link failure "undefined reference to `_dlmmap'" and "undefined reference > to `_dlmunmap'" Sorry, I got distracted from this one for a bit. I'm working on a fix. cheers, DaveK

Re: gcc trunk 20070110 build failure (--enable-targets=all i486-linux-gnu)

On Wed, Jan 10, 2007 at 12:07:28PM +0100, Matthias Klose wrote: > trunk configured on i486 (on x86_64 hardware) with > > --enable-targets=all i486-linux-gnu > > fails to configure the first 64bit library (libiberty), not finding > the correct libgcc. libgcc uses the same config-ml.in to enable

Re: [gcc trunk on cygwin] ../../gcc/gcc/config/i386/msformat-c.c:[39,40,41,42,43,44,58,75,87,110,128,145] error: enum conversion in initialization is invalid in C++

Christian Joensson wrote: > ../../gcc/gcc/config/i386/msformat-c.c:39: error: enum conversion in > initialization is invalid in C++ > Any hints on what's going on and how to cure the issue? Yep: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00125.html (and thread). cheers, DaveK

Re: [gcc trunk on cygwin] ../../gcc/gcc/config/i386/msformat-c.c:[39,40,41,42,43,44,58,75,87,110,128,145] error: enum conversion in initialization is invalid in C++

2009/5/5 Dave Korn : > Christian Joensson wrote: > >> ../../gcc/gcc/config/i386/msformat-c.c:39: error: enum conversion in >> initialization is invalid in C++ > >> Any hints on what's going on and how to cure the issue? > >  Yep: http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00125.html (and thread).