Hi,
On Thu, Mar 6, 2008 at 6:23 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 06, 2008 at 07:50:12AM -0800, H. Peter Anvin wrote:
> > H.J. Lu wrote:
> > >I agree with it. There is no right or wrong here Let's start from
> > >scratch and figure out
> > >what is the best way to han
Hi all,
regtesting on i686-apple-darwin9 I see :
FAIL: gcc.c-torture/compile/pr33009.c -O2 (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer
(internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c -O3 -fomit-frame-pointer (test
for excess errors
Hi,
Sunday 27 January 2008 16:37:37 tarihinde Dave Korn şunları yazmıştı:
> I'm using the very latest autogen:
>
> /gnu/gcc/obj $ autogen --version
> autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.9.4
>
> It doesn't seem to like our syntax in inclhacks.def any more:
>
> check
Monday 14 January 2008 12:34:03 tarihinde Paolo Bonzini şunları yazmıştı:
> Why not fixing the handful of packages with a /^#define PACKAGE/d,
> instead of adding -fpermissive to the 50 users of those broken packages?
That simple fix won't work, there might be installed headers which depend on
de
Sunday 13 January 2008 18:40:25 tarihinde Gabriel Dos Reis şunları yazmıştı:
> | real life testcase shows that problem stems from
> | autoconf and its config.h. Projects end up defining things like
> | HAVE_STDLIB_H twice which is not harmful at all but now causes an error
> | if g++ is used.
>
> T
Sunday 13 January 2008 18:10:00 tarihinde Richard Guenther şunları yazmıştı:
> On Jan 13, 2008 5:10 PM, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> > Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı:
> > > Ismail Dönmez <[EMAIL PROTECTED]> wr
Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > That was just an example, real life testcase shows that problem stems
> > from autoconf and its config.h. Projects end up defining things like
> > H
Sunday 13 January 2008 17:41:03 tarihinde Gabriel Dos Reis şunları yazmıştı:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> | Hi again,
> |
> | Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları
> |
> | yazmıştı:
> | > For your particular exampl
Hi again,
Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları
yazmıştı:
> For your particular example, you could open a regression bug against
> 4.3 that says:
> * '"foo' redefined" is not mandated by the standard or it is not
> serious enough, so it should not be a pedwarn j
Wednesday 09 January 2008 00:51:32 tarihinde şunları yazmıştınız:
> > Oh that clears up my confusion. So the right fix would be downgrading
> > this redefinition problem to be pedwarn instead. But I see no point in
> > creating a bug report if its just gonna be closed as invalid, so I hope
> > we c
Hi Manuel,
Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları
yazmıştı:
> I implemented the change as the fix to a bug that was reported by
> fellow (and more senior) GCC developers. Let me try to explain
> (although, I hoped that it will be fairly clear from
> gcc.gnu.org/g
Tuesday 08 January 2008 23:34:13 tarihinde Joe Buck şunları yazmıştı:
> There's certainly an argument that this change is ill-advised. However,
> your statements in the last paragraph aren't true: most quality open
> source projects have a "no warnings" rule (or at least try to eliminate
> warning
Hi all,
Looks like gcc 4.3 has some rather inconvenient changes in C++ FE, with the
latest trunk. Lets see with an example :
[~]> cat test.cpp
#define foo bar
#define foo baz
[~]> g++ -c test.cpp
test.cpp:2:1: error: "foo" redefined
test.cpp:1:1: error: this is the location of the previous defi
Saturday 29 December 2007 19:49:13 tarihinde Ian Lance Taylor şunları
yazmıştı:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları
yazmıştı:
> > > Hi all,
> > >
> > > I am doing glibc 4.3 r
Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı:
> Hi all,
>
> I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day
> and I see 3 tests fail :
>
> math/test-float
> math/test-ildoubl
> math/test-ifloat
>
> The erorrs
Friday 28 December 2007 16:20:52 tarihinde Ismail Dönmez şunları yazmıştı:
> libio/tst-fopenloc2
> libio/tst-fopenloc
>
> These two seems to be a new gcc regression, they crash when compiled with
> gcc trunk.
Ok I identified that commit 130788 [0] broke these testcases , the sam
Saturday 22 December 2007 19:11:32 tarihinde Ismail Dönmez şunları yazmıştı:
> Hi all,
>
> I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day
> and I see 3 tests fail :
>
> math/test-float
> math/test-ildoubl
> math/test-ifloat
>
> The erorrs
Hi all,
I am doing glibc 4.3 regression tests using gcc 4.3 trunk nearly every day and
I see 3 tests fail :
math/test-float
math/test-ildoubl
math/test-ifloat
The erorrs are all similar :
Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i
Result:
is: 0.00
Wednesday 19 December 2007 22:11:22 tarihinde Doug Gregor şunları yazmıştı:
> On Dec 19, 2007 3:02 PM, <[EMAIL PROTECTED]> wrote:
> > One last point. In looking for the rationale behind this warning, I
> > searched for examples of it. I didn't find any discussion on this list.
> > What I did fi
Tuesday 18 December 2007 20:47:29 tarihinde Mike Stump şunları yazmıştı:
> On Dec 18, 2007, at 10:08 AM, Ismail Dönmez wrote:
> > Any schedule for fixing Obj-C++ regressions on mainline?
>
> Same answer. My hope would be that people that introduce regressions
> would fix them..
Hi Mike,
Tuesday 18 December 2007 20:04:45 tarihinde Mike Stump şunları yazmıştı:
> On Dec 17, 2007, at 9:45 PM, Sven Herzberg wrote:
> > I was just browsing the gcc-list to see if there are any updates on
> > the Objective-C 2.0 extensions. Can you please send and email to the
> > gcc-list with t
Thursday 06 December 2007 21:28:59 Vincent Lefevre yazmıştı:
> On 2007-12-06 10:15:17 -0800, Ian Lance Taylor wrote:
> > Distributed version systems like git or Mercurial have some advantages
> > over Subversion.
>
> It's surprising that you don't mention svk, which is based on top
> of Subversion[
Thursday 06 December 2007 13:57:06 Johannes Schindelin yazmıştı:
[...]
> So I fully expect an issue like Daniel's to be resolved in a matter of
> minutes on the git list, if the OP gives us a chance. If we are not even
> Cc'ed, you are completely right, she or he probably does not want the
> issue
Wednesday 05 December 2007 21:08:41 Daniel Berlin yazmıştı:
> So I tried a full history conversion using git-svn of the gcc
> repository (IE every trunk revision from 1-HEAD as of yesterday)
> The git-svn import was done using repacks every 1000 revisions.
> After it finished, I used git-gc --aggre
Wednesday 28 November 2007 Tarihinde 04:04:18 yazmıştı:
> $ svn -q co svn://gcc.gnu.org/svn/gcc/trunk gcc
> $ du -s .
> 1044451 .
> $
>
> It's 1'069'517'824 characters made from keyboards and generators!!!
>
> That massive!!! And slower checkout after several minutes!!!
>
> Is not there any another
Saturday 24 November 2007 Tarihinde 03:44:04 yazmıştı:
> Hi all,
>
> I am trying to bootstrap gcc with the following config :
>
> ../configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0
> --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
> --datadir=/usr/share/gcc/i686-pc-linux
Saturday 24 November 2007 Tarihinde 03:44:04 yazmıştı:
> Hi all,
>
> I am trying to bootstrap gcc with the following config :
[...]
Sorry for the noise, looks like my snapshot tarball build from git repo using
git-archive has some problems as the gcc-4.3-20071123 snapshot bootstrapped
fine.
Tha
Hi all,
I am trying to bootstrap gcc with the following config :
../configure --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.3.0
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include
--datadir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0
--mandir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/man
Tuesday 20 November 2007 Tarihinde 03:12:35 yazmıştı:
> Does someone provide a Git mirror of the GCC repository? Or a CVS
> mirror? (With CVS you at least know what to expect...)
Nice people over infradead.org does,
http://git.infradead.org/?p=gcc.git;a=summary .
To clone
git clone git://git.
On Monday 18 June 2007 04:23:35 michael.a wrote:
> I'm sorry, but can anyone get through to any of these mirrors ever:
>
> http://gcc.gnu.org/mirrors.html
The first mirror there, ftp://gd.tuwien.ac.at/gnu/gcc/ works fine. But next
time please use gcc-help mailing list for such questions. Thanks.
On Tuesday 08 May 2007 14:35:26 Richard Guenther wrote:
[...]
> Did you verify this is actually the same problem? Note that this PR
> isn't marked as
> broken on 4.2.0 or as a regression, so you should probably file a new
> bugreport against 4.2.0 and link to the old one.
Filed as PR31865.
--
L
On Tuesday 08 May 2007 14:35:26 Richard Guenther wrote:
> On 5/8/07, Ismail Dönmez <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > Fix for PR31264 doesn't seem to be checked into 4.2.0 branch which breaks
> > MPlayer SVN compilation with :
> >
> > cc -I
Hi,
Fix for PR31264 doesn't seem to be checked into 4.2.0 branch which breaks
MPlayer SVN compilation with :
cc -I../libavcodec -I../libavformat -Wdeclaration-after-statement -I. -I..
-I../libavutil -O4 -march=pentium-m -mtune=pentium-m -pipe
-ffast-math -fomit-frame-pointer -D_REENTRANT -D_LA
On Monday 16 April 2007 20:02:33 Theodore Papadopoulo wrote:
> The piece of code attached to this mail does not compile with 4.3.0
> 20070113 (sorry this is rather old, but that's what I had available). The
> architecture (although not relevant IMHO)
> is i686-pc-linux-gnu.
>
> [ Even though this i
On Monday 19 March 2007 23:00:09 Eric Lemings wrote:
> Hi,
>
> The following code compiles fine in GCC 4.1.
>
> enum E { e };
> struct S {
> E v:5;
> };
> S s;
> int main() { if (!s.v) return 0; }
>
> In 4.2 (20070307), it gives the following error:
>
> t
On Wednesday 31 January 2007 11:26:38 Ismail Dönmez wrote:
> On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote:
> > Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > > I am getting this when I try to compile gcc trunk:
> > >
> > > ../../libcpp/../i
On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > I am getting this when I try to compile gcc trunk:
> >
> > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe
> > -fomit-frame-pointer -
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote:
> > make STAGE1_CFLAGS="-O"
> > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer
> > -U_FORTIFY_SOURCE" profiledbootstrap
>
> Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler.
And I am still getting floating p
On Tuesday 30 January 2007 21:44:15 Eric Botcazou wrote:
> > make STAGE1_CFLAGS="-O"
> > BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer
> > -U_FORTIFY_SOURCE" profiledbootstrap
>
> Do not set STAGE1_CFLAGS, you may run into bugs of the bootstrap compiler.
Ok btw bootstrapping compiler is,
On Tuesday 30 January 2007 18:43:52 Ian Lance Taylor wrote:
> Ismail Dönmez <[EMAIL PROTECTED]> writes:
> > I am getting this when I try to compile gcc trunk:
> >
> > ../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe
> > -fomit-frame-pointer -
Hi all,
I am getting this when I try to compile gcc trunk:
../../libcpp/../include -I../../libcpp/include -march=i686 -O2 -pipe
-fomit-frame-pointer -U_FORTIFY_SOURCE -fprofile-use -W -Wall -Wwrite-strings
-Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attrib
41 matches
Mail list logo
