Interesting build failure on trunk

[Ismail Dönmez]

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-attribute 
-pedantic -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include 
-I../../libcpp/include  -c -o 
files.o -MT files.o -MMD -MP -MF .deps/files.Po ../../libcpp/files.c
../../libcpp/files.c: In function 'read_name_map':
../../libcpp/files.c:1238: internal compiler error: Floating point exception
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [files.o] Error 1


Did anyone hit this before?

Regards,
ismail

Re: Interesting build failure on trunk

[Ismail Dönmez]

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 -U_FORTIFY_SOURCE -fprofile-use -W -Wall
> > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> > -Wold-style-definition -Wmissing-format-attribute -pedantic
> > -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include
> > -I../../libcpp/include  -c -o files.o -MT files.o -MMD -MP -MF
> > .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function
> > 'read_name_map':
> > ../../libcpp/files.c:1238: internal compiler error: Floating point
> > exception Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See http://gcc.gnu.org/bugs.html> for instructions.
>
> libcpp/files.c:1238 seems to be a call to memcpy.  I don't see
> anyplace a floating point exception might come from.  I've certainly
> never seen anything like that.

FWIW I configure like this:

../configure   --enable-shared --enable-threads=posix --enable-__cxa_atexit 
--enable-clocale=gnu 
--disable-libssp --disable-nls --enable-ssp --enable-libstdcxx-allocator=new 
--enable-version-specific-runtime-libs 
--without-included-gettext --with-system-zlib --prefix=/usr/share/gcc-snapshot 
--enable-languages=c,c++

And make with :

make STAGE1_CFLAGS="-O" 
BOOT_CFLAGS="-march=i686 -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE" 
profiledbootstrap

Regards,
ismail

Re: Interesting build failure on trunk

[Ismail Dönmez]

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,

Using built-in specs.
Target: i686-pc-linux-gnu
Configured 
with: /var/pisi/gcc-4.2.0-15/work/gcc-4.2-20070102/configure --prefix=/usr 
--bindir=/usr/i686-pc-linux-gnu/gcc/4.2.0 
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include 
--datadir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0 
--mandir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/man 
--infodir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/info 
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include/g++-v3 
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu 
--disable-libgcj --disable-libssp --disable-multilib --disable-nls 
--disable-werror --enable-clocale=gnu --enable-__cxa_atexit 
--enable-languages=c,c++,objc,fortran --enable-libstdcxx-allocator=new 
--enable-shared --enable-ssp --enable-threads=posix 
--enable-version-specific-runtime-libs --without-included-gettext 
--without-system-libunwind --with-system-zlib
Thread model: posix
gcc version 4.2.0 20070124 (prerelease) (Pardus Linux)

Regards,
ismail

Re: Interesting build failure on trunk

[Ismail Dönmez]

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 point exception even with a bare make. Any way 
to debug this?

Regards,
ismail

Re: Interesting build failure on trunk

[Ismail Dönmez]

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 -U_FORTIFY_SOURCE -fprofile-use -W -Wall
> > -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> > -Wold-style-definition -Wmissing-format-attribute -pedantic
> > -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include
> > -I../../libcpp/include  -c -o files.o -MT files.o -MMD -MP -MF
> > .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function
> > 'read_name_map':
> > ../../libcpp/files.c:1238: internal compiler error: Floating point
> > exception Please submit a full bug report,
> > with preprocessed source if appropriate.
> > See http://gcc.gnu.org/bugs.html> for instructions.
>
> libcpp/files.c:1238 seems to be a call to memcpy.  I don't see
> anyplace a floating point exception might come from.  I've certainly
> never seen anything like that.

I think this is an hardware error recently got a Bus Error when doing an 
rm -rf, I hope to change laptop's RAMs soon. I will report back.

Thank you for your replies.

Regards,
ismail

Re: Interesting build failure on trunk

[Ismail Dönmez]

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/../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-attribute -pedantic
> > > -Wno-long-long -Werror -I../../libcpp -I. -I../../libcpp/../include
> > > -I../../libcpp/include  -c -o files.o -MT files.o -MMD -MP -MF
> > > .deps/files.Po ../../libcpp/files.c ../../libcpp/files.c: In function
> > > 'read_name_map':
> > > ../../libcpp/files.c:1238: internal compiler error: Floating point
> > > exception Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > See http://gcc.gnu.org/bugs.html> for instructions.
> >
> > libcpp/files.c:1238 seems to be a call to memcpy.  I don't see
> > anyplace a floating point exception might come from.  I've certainly
> > never seen anything like that.
>
> I think this is an hardware error

Ok its not, I tried to build on AMD64 3500+ 1GB RAM ( unlike my Centrino 
laptop, totally different hardware ) and it crashes in the same exact way. 
now my guess is host compiler is somehow hosed , bad news for gcc 4.2 I 
guess.

Regards,
ismail

Re: Bitfield conversion bug in 4.2?

[Ismail Dönmez]

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:
>
>   test.cpp: In function 'int main()':
>   test02.cpp:6: error: could not convert 's.S::v' to 'bool'
>   test02.cpp:6: error: in arguument to unary !
>
> Is this a bug or new behavior?  If the latter, what is this attributed
> to?

It should be fixed in 4.2 branch now, see 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31157 .


-- 
Happiness in intelligent people is the rarest thing I know. (Ernest Hemingway)

Ismail Donmez ismail (at) pardus.org.tr
GPG Fingerprint: 7ACD 5836 7827 5598 D721 DF0D 1A9D 257A 5B88 F54C
Pardus Linux / KDE developer


pgpF7tmwa88It.pgp
Description: PGP signature

Re: Potential bug with g++ and OpenMP

[Ismail Dönmez]

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 is not relevant here, a similar error happens with
> the redhat version gcc-4.1.1 (although the message is slightly
> different and more confusing). ]
>
> I get the following error message:
>
> -> g++ -fopenmp Test.C
>
> Test.C: In constructor ‘R::R()’:
> Test.C:18: error: invalid use of incomplete type ‘struct R::R()::B’
> Test.C:9: error: declaration of ‘struct R::R()::B’

FWIW it gives the same error with 

gcc version 4.2.0 20070317 (prerelease) and 
gcc version 4.3.0 20070414 (experimental)

Regards,
ismail

-- 
Life is a game, and if you aren't in it to win,
what the heck are you still doing here?

-- Linus Torvalds (talking about open source development)


signature.asc
Description: This is a digitally signed message part.

Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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 definition

I don't know the reasoning behind this change but this breaks many C++ 
programs unless -fpermissive is used. Why? Because everybody loves to install 
their own config.h (Python, libmp4v2 being nice examples) which just 
carelessly #define anything its asked for with ifndef ... endif .

Now flash back to real world: this breaks any C++ application that uses 
Python, libmp4v2, libjpeg and possibly many others. And I think this is a 
real bad behaviour change and I am not sure if its worth all the trouble.

So I am asking, would C++ FE maintainers would agree to revert this into a 
warning as in C FE now.

I welcome and value your comments, so please speak up.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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
> warnings), and most programmers know about #undef.

Interesting assumption because knowing about #undef doesn't cut it because 
autoconf will happily #define without ifndef etc.

> Since people have  already built whole distros with the gcc from the trunk, 
> clearly theyare managing to build C++ applications that use 
> Python,libmp4v2, libjpeg etc. 

Yes true because they use -fpermissive which will let this error into a 
warning, which also suggests this change is not good.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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/gcc-4.3/changes.html).

Yeah I know this change is documented at least.

> We have a series of diagnostics that are important or required by the
> standard (or both). Those are called pedwarns. It is an unfortunate
> name for two reasons: 1) Not all pedwarns are enabled by -pedantic,
> some are enabled by default; and 2) pedwarns can be either warnings or
> errors, and what they are depends on command-line options and the
> default of each front-end.  In fact, pedwarnss are warnings by default
> in the C front-end. But they are errors by default in the C++
> front-end unless you use -fpermissive so they are downgraded to
> warnings.
>
> Before GCC 4.3, the C++ preprocessor was ignoring the default of the
> C++ front-end. In fact, there was an inconsistence between the
> settings of the C++ preprocessor and the settings of the C++
> front-end. It worked for a few things (-pedantic-errors worked fine),
> but not for others (the default settings and the effect of
> -fpermissive). The inconsistency was evident in the code and if you
> played with combinations of -pedantic-errors and -fpermissive.

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 can discuss 
if its feasible to downgrade this error to be a pedwarn.

What I see right now this distributions plug -fpermissive in and just go away. 
But I don't like workarounding gcc this way. I hope we can all agree that 
downrading this error to be a pedwarn is the correct way to go.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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 can discuss if its feasible to downgrade this error to be a pedwarn.
> >
> > What I see right now this distributions plug -fpermissive in and just go
> > away. But I don't like workarounding gcc this way. I hope we can all
> > agree that downrading this error to be a pedwarn is the correct way to
> > go.
>
> I am sorry you didn't understand my email and didn't read it
> completely. I tried my best.

Sorry for misunderstanding, Andrew pointed out how I get it all wrong. Reading 
your mail again, you propose two possible fixes. Like you I am not in the 
position to see which would be the best solution.

So we need C++ FE maintainers to comment if they agree with one of those fixes 
at least. Though for me the first solution looks more plausible.

Thanks again,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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 just a normal warning;
> or

Looks like this is actually mandated by standard :-( , thats what I am told on 
#gcc anyway :)

> * "'foo' redefined", although mandated by the standard, is a nuisance
> and irrelevant, it should only be active when -pedantic is given and
> not by default.

I am not sure if this is irrelevant for all cases, so the current behaviour 
looks correct. The right way would be fixing all those apps not installing 
their config.h and not pollute global namespace but thats a huge task given 
that many projects are affected.

So for now I guess we'll have to stick to -fpermissive. Thanks for your time 
and patience.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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 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 just a normal warning;
> | > or
> |
> | Looks like this is actually mandated by standard :-( , thats what I am
> | told on #gcc anyway :)
>
> #define foo bar
> #define foo baz
>
> is asking for trouble -- one should look for fixing the source of that
> inconsistency.

That was just an example, 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.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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
> > HAVE_STDLIB_H twice which is not harmful at all but now causes an error
> > if g++ is used.
>
> Redefinitions with the same replacement list are not an error.

Ok but that still doesn't cover the general use of

#define PACKAGE_NAME foobar

etc.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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]> 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
> > > > HAVE_STDLIB_H twice which is not harmful at all but now causes an
> > > > error if g++ is used.
> > >
> > > Redefinitions with the same replacement list are not an error.
> >
> > Ok but that still doesn't cover the general use of
> >
> > #define PACKAGE_NAME foobar
> >
> > etc.
>
> But that's just bugs that need to be fixed.

I think we already agreed that this is just too many packages to fix and that 
this warning should only be an error with -pedantic. People already started 
adding #undef hacks to workaround this, others are building 
with -fpermissive.

So we should should just let Manu finish up his patch and get a review as C++ 
FE maintainers agreed as well.

Regards,
ismail


-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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.
>
> The problem is that any semantics of the above -- that is not an error
> or silent ignorance -- is order-dependent, which is worse to debug.

True but lots of real world applications are falling apart, is it worth to 
break them all anyway? Also with -pedantic you will still get an error. I 
think its a good compromise.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Changes in C++ FE regarding pedwarns to be errors are harmful

[Ismail Dönmez]

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 
definitions in config.h . This might be broken but there are just too many 
cases to fix. At least gcc should have warned in gcc 4.3 that this will be an 
error in next release and do this in 4.4 instead of breaking stuff en masse.

Regards,
ismail


-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: inclhacks vs. latest autogen?

[Ismail Dönmez]

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:
>
> checking whether to enable maintainer-specific portions of Makefiles... yes
> configure: creating ./config.status
> /bin/sh ./config.status Makefile
> config.status: creating Makefile
> make[3]: Leaving directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> make[3]: Entering directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> cd /gnu/gcc/gcc/fixincludes ; /bin/sh ./genfixes
> AutoGen-ing fixincl.x
> autogen Error: Invalid input char '*' in inclhack.def on line 1088
> Makefile:128: *** [/gnu/gcc/gcc/fixincludes/fixincl.x] Error 1
>
> #0  /gnu/gcc/gcc/fixincludes/fixincl.x at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:128
> #1  fixincl.o at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:116
> #2  full-stamp at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:105
> #3  oneprocess at
> /win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes/Makefile:102
> #4  all at ??
> make[3]: Leaving directory
> `/win/i/FSF-Gcc/obj/build-i686-pc-cygwin/fixincludes'
> Command-line arguments:
>   "all"
> Makefile:2784: *** [all-build-fixincludes] Error 2
>
>   It's pointing at some globs in shell syntax:
>
> /gnu/gcc/obj $ cat -n /gnu/gcc/gcc/fixincludes/inclhack.def | grep -C3 1088
>   1085   */
>   1086  fix = {
>   1087  hackname  = bsd_stdio_attrs_conflict;
>   1088  mach  = *-*-*bsd*;
>   1089  mach  = *-*-*darwin*;
>   1090  files = stdio.h;
>   1091  select= "^#define[ \t]*vfscanf[ \t]*__svfscanf[ \t]*$";
> /gnu/gcc/obj $
>
>
>   This isn't a recent change, so I'm assuming autogen has changed.  What
> versions are other people running?

I use the attached patch successfully, I didn't submit it yet because I 
couldn't test it with older autogen. Testing is appreciated.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.
--- fixincludes/inclhack.def	2007-12-29 02:14:35.0 +0200
+++ fixincludes/inclhack.def	2007-12-31 04:21:00.0 +0200
@@ -1085,8 +1085,8 @@
  */
 fix = {
 hackname  = bsd_stdio_attrs_conflict;
-mach  = *-*-*bsd*;
-mach  = *-*-*darwin*;
+mach  = "*-*-*bsd*";
+mach  = "*-*-*darwin*";
 files = stdio.h;
 select= "^#define[ \t]*vfscanf[ \t]*__svfscanf[ \t]*$";
 c_fix = format;
@@ -1303,7 +1303,7 @@
  */
 fix = {
 hackname  = freebsd_gcc3_breakage;
-mach  = *-*-freebsd*;
+mach  = "*-*-freebsd*";
 files = sys/cdefs.h;
 select= '^#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7$';
 bypass= '__GNUC__[ \t]*([>=]=[ \t]*[3-9]|>[ \t]*2)';
@@ -1320,7 +1320,7 @@
  */
 fix = {
 hackname  = freebsd_gcc4_breakage;
-mach  = *-*-freebsd*; 
+mach  = "*-*-freebsd*"; 
 files = sys/cdefs.h;
 select= '^#if __GNUC__ == 2 && __GNUC_MINOR__ >= 7 \|\| __GNUC__ == 3$';
 c_fix = format;
@@ -1619,7 +1619,7 @@
 
 fix = {
  hackname  = hppa_hpux_fp_macros;
- mach  = hppa*-hp-hpux11*;
+ mach  = "hppa*-hp-hpux11*";
  files = math.h;
  select= "#[ \t]*define[ \t]*FP_NORMAL.*\n"
 		 "#[ \t]*define[ \t]*FP_ZERO.*\n"
@@ -1728,7 +1728,7 @@
  */
 fix = {
 hackname  = hpux11_abs;
-mach  = ia64-hp-hpux11*;
+mach  = "ia64-hp-hpux11*";
 files = stdlib.h;
 select= "ifndef _MATH_INCLUDED";
 c_fix = format;
@@ -2670,7 +2670,7 @@
  */
 fix = {
 hackname  = netbsd_c99_inline_1;
-mach  = *-*-netbsd*;
+mach  = "*-*-netbsd*";
 files = signal.h;
 select= "extern __inline int";
 
@@ -2683,7 +2683,7 @@
 
 fix = {
 hackname  = netbsd_c99_inline_2;
-mach  = *-*-netbsd*;
+mach  = "*-*-netbsd*";
 files = signal.h;
 select= "#define _SIGINLINE extern __inline";
 
@@ -2705,7 +2705,7 @@
  */
 fix = {
 hackname  = netbsd_extra_semicolon;
-mach  = *-*-netbsd*;
+mach  = "*-*-netbsd*";
 files = sys/cdefs.h;
 select= "#define[ \t]*__END_DECLS[ \t]*};";
 

Lots of new test failures on trunk due to unrecognizable insn

[İsmail Dönmez]

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)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
-funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
-funroll-loops  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr33009.c  -Os  (internal compiler error)
FAIL: gcc.c-torture/compile/pr33009.c  -Os  (test for excess errors)


Log shows :

/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:
In function 'foo':
/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30:
error: unrecognizable insn:
(insn 
177/Users/cartman/Sources/gcc/gcc/testsuite/gcc.c-torture/compile/pr11832.c:30:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

This is a new regression introduced under 48 hours. Any ideas?

Regards,
ismail

-- 
UNIX is basically a simple operating system, but you have to be a
genius to understand the simplicity. - Dennis Ritchie

Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag

[İsmail Dönmez]

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 handle this, assuming we are defining a new psABI.
>
>  BTW, just tested icc and icc doesn't generate cld either (so it matches the
>  new gcc behavior).
>  char buf1[32], buf2[32];
>  void bar (void);
>  void foo (void)
>  {
>   __builtin_memset (buf1, 0, 32);
>   bar ();
>   __builtin_memset (buf2, 0, 32);
>  }

Also LKML discussion pointed out that Solaris gets this right too.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

PR31264 on 4.2.0 branch

[Ismail Dönmez]

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_LARGEFILE_SOURCE 
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include -I/usr/include/  
-I/usr/include/SDL  -D_REENTRANT  -I/usr/include/freetype2 -I/usr/include   -c 
-o 
demux_vqf.o demux_vqf.c
demux_vqf.c: In function 'demux_open_vqf':
demux_vqf.c:24: internal compiler error: in build_int_cst_wide, at tree.c:864

[/packages/mplayer]> cc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured 
with: /var/pisi/gcc-4.2.0-23/work/gcc-4.2.0-20070430/configure --prefix=/usr 
--bindir=/usr/i686-pc-linux-gnu/gcc/4.2.0 
--includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include 
--datadir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0 
--mandir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/man 
--infodir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/info 
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include/g++-v3 
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu 
--disable-libgcj --disable-libssp --disable-multilib --disable-nls 
--disable-werror --enable-clocale=gnu --enable-__cxa_atexit 
--enable-languages=c,c++,objc,fortran --enable-libstdcxx-allocator=new 
--enable-shared
 --enable-ssp --enable-threads=posix --enable-version-specific-runtime-libs 
--without-included-gettext --without-system-libunwind --with-system-zlib
Thread model: posix
gcc version 4.2.0 20070430 (prerelease) (Pardus Linux)

It seems to be a one liner fix which is in mainline for some time, would it be 
ok to check it into 4.2.0 branch too?

Regards,
ismail

-- 
Le mieux est l'ennemi du bien.

Re: PR31264 on 4.2.0 branch

[Ismail Dönmez]

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../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_LARGEFILE_SOURCE
> > -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I/usr/include
> > -I/usr/include/  -I/usr/include/SDL  -D_REENTRANT 
> > -I/usr/include/freetype2 -I/usr/include   -c -o demux_vqf.o demux_vqf.c
> > demux_vqf.c: In function 'demux_open_vqf':
> > demux_vqf.c:24: internal compiler error: in build_int_cst_wide, at
> > tree.c:864
> >
> > [/packages/mplayer]> cc -v
> > Using built-in specs.
> > Target: i686-pc-linux-gnu
> > Configured
> > with: /var/pisi/gcc-4.2.0-23/work/gcc-4.2.0-20070430/configure
> > --prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc/4.2.0
> > --includedir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include
> > --datadir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0
> > --mandir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/man
> > --infodir=/usr/share/gcc/i686-pc-linux-gnu/4.2.0/info
> > --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.2.0/include/g++-v
> >3 --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj
> > --disable-libssp --disable-multilib --disable-nls --disable-werror
> > --enable-clocale=gnu --enable-__cxa_atexit
> > --enable-languages=c,c++,objc,fortran --enable-libstdcxx-allocator=new
> > --enable-shared --enable-ssp --enable-threads=posix
> > --enable-version-specific-runtime-libs --without-included-gettext
> > --without-system-libunwind --with-system-zlib Thread model: posix
> > gcc version 4.2.0 20070430 (prerelease) (Pardus Linux)
> >
> > It seems to be a one liner fix which is in mainline for some time, would
> > it be ok to check it into 4.2.0 branch too?
>
> 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.

The file and function is the same but the code looks different. I'll file a PR 
for 4.2.0 branch. Thanks.

Regards,
ismail


-- 
Le mieux est l'ennemi du bien.


signature.asc
Description: This is a digitally signed message part.

Re: PR31264 on 4.2.0 branch

[Ismail Dönmez]

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.

-- 
Le mieux est l'ennemi du bien.


signature.asc
Description: This is a digitally signed message part.

Re: I'm sorry, but this is unacceptable (union members and ctors)

[Ismail Dönmez]

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.

/ismail

-- 
Perfect is the enemy of good

Re: Build failure of trunk on i686-pc-gnu-linux

[Ismail Dönmez]

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.infradead.org/gcc.git

Regards,
ismail

-- 
Faith is believing what you know isn't so -- Mark Twain

Re: Infinite loop when trying to bootstrap trunk

[Ismail Dönmez]

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.

Thanks,
ismail

-- 
Faith is believing what you know isn't so -- Mark Twain

Infinite loop when trying to bootstrap trunk

[Ismail Dönmez]

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 
--infodir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/info 
--with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v3 
--host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj 
--disable-libssp --disable-multilib --disable-nls --disable-werror 
--disable-checking 
--enable-clocale=gnu --enable-__cxa_atexit 
--enable-languages=c,c++,fortran,objc,obj-c++,treelang 
--enable-libstdcxx-allocator=new 
--enable-shared --enable-ssp --enable-threads=posix 
--enable-version-specific-runtime-libs --without-included-gettext 
--without-system-libunwind --with-system-zlib

And build freezes at this point (stuck for ~1 hour and going on 2GB RAM Quad 
Core Xeon ) :

/var/pisi/gcc-4.3.0_pre20071123-30/work/gcc-4.3.0_20071123/build-default-i686-pc-linux-gnu/./prev-gcc/xgcc
 
-B/var/pisi/gcc-4.3.0_pre20071123-30/work/gcc-4.3.0_20071123/build-default-i686-pc-linux-gnu/./prev-gcc/
 -B/usr/i686-pc-linux-gnu/bin/ -c   
-march=i686 -ftree-vectorize -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE 
-fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute 
-pedantic -Wno-long-long -Wno-variadic-macros   
 -Wno-overlength-strings-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. 
-I../../gcc/../include -I../../gcc/../libcpp/include  
-I../../gcc/../libdecnumber 
-I../../gcc/../libdecnumber/bid -I../libdecnumberinsn-attrtab.c -o 
insn-attrtab.o


I attach gdb to build-default-i686-pc-linux-gnu/./prev-gcc/xgcc and break to 
get this backtrace :

#0  0xa7fae410 in __kernel_vsyscall ()
#1  0xa7e5bf93 in waitpid () from /lib/libc.so.6
#2  0x0806608a in pex_wait (obj=0x808aca0, pid=966, status=0x80850d0, 
time=0x0) at ../../libiberty/pex-unix.c:100
#3  0x0801 in pex_unix_wait (obj=0x808aca0, pid=966, status=0x80850d0, 
time=0x0, done=0, errmsg=0xafc05a54, err=0xafc05a50)
at ../../libiberty/pex-unix.c:486
#4  0x08065d31 in pex_get_status_and_time (obj=0x808aca0, done=0, 
errmsg=0xafc05a54, err=0xafc05a50) at ../../libiberty/pex-common.c:531
#5  0x08065d94 in pex_get_status (obj=0x808aca0, count=2, vector=0xafc05a80) 
at ../../libiberty/pex-common.c:551
#6  0x0804c6b2 in execute () at ../../gcc/gcc.c:3012
#7  0x08050f44 in do_spec (
spec=0x806828c "%{E|M|MM:
%(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)}  %{!E:%{!M:
%{!MM:  %{traditional|ftraditional:%eGNU C no longer 
supports -traditional without -E}   %{!combine:\t  %{sa"...) 
at ../../gcc/gcc.c:4436
#8  0x0805654e in main (argc=36, argv=0xafc05dc4) at ../../gcc/gcc.c:6684


For information, 2 days old trunk bootstrapped fine. Any idea is appreciated.

Regards,
ismail

-- 
Faith is believing what you know isn't so -- Mark Twain

Re: Infinite loop when trying to bootstrap trunk

[Ismail Dönmez]

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-gnu/4.3.0
> --mandir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/man
> --infodir=/usr/share/gcc/i686-pc-linux-gnu/4.3.0/info
> --with-gxx-include-dir=/usr/lib/gcc/i686-pc-linux-gnu/4.3.0/include/g++-v3
> --host=i686-pc-linux-gnu --build=i686-pc-linux-gnu --disable-libgcj
> --disable-libssp --disable-multilib --disable-nls --disable-werror
> --disable-checking --enable-clocale=gnu --enable-__cxa_atexit
> --enable-languages=c,c++,fortran,objc,obj-c++,treelang
> --enable-libstdcxx-allocator=new --enable-shared --enable-ssp
> --enable-threads=posix --enable-version-specific-runtime-libs
> --without-included-gettext --without-system-libunwind --with-system-zlib
>
> And build freezes at this point (stuck for ~1 hour and going on 2GB RAM
> Quad Core Xeon ) :
>
> /var/pisi/gcc-4.3.0_pre20071123-30/work/gcc-4.3.0_20071123/build-default-i6
>86-pc-linux-gnu/./prev-gcc/xgcc
> -B/var/pisi/gcc-4.3.0_pre20071123-30/work/gcc-4.3.0_20071123/build-default-
>i686-pc-linux-gnu/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -march=i686
> -ftree-vectorize -O2 -pipe -fomit-frame-pointer -U_FORTIFY_SOURCE
> -fprofile-generate -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   
> -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../include
> -I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber
> -I../../gcc/../libdecnumber/bid -I../libdecnumberinsn-attrtab.c -o
> insn-attrtab.o
>
>
> I attach gdb to build-default-i686-pc-linux-gnu/./prev-gcc/xgcc and break
> to get this backtrace :
>
> #0  0xa7fae410 in __kernel_vsyscall ()
> #1  0xa7e5bf93 in waitpid () from /lib/libc.so.6
> #2  0x0806608a in pex_wait (obj=0x808aca0, pid=966, status=0x80850d0,
> time=0x0) at ../../libiberty/pex-unix.c:100
> #3  0x0801 in pex_unix_wait (obj=0x808aca0, pid=966, status=0x80850d0,
> time=0x0, done=0, errmsg=0xafc05a54, err=0xafc05a50)
> at ../../libiberty/pex-unix.c:486
> #4  0x08065d31 in pex_get_status_and_time (obj=0x808aca0, done=0,
> errmsg=0xafc05a54, err=0xafc05a50) at ../../libiberty/pex-common.c:531
> #5  0x08065d94 in pex_get_status (obj=0x808aca0, count=2,
> vector=0xafc05a80) at ../../libiberty/pex-common.c:551
> #6  0x0804c6b2 in execute () at ../../gcc/gcc.c:3012
> #7  0x08050f44 in do_spec (
> spec=0x806828c "%{E|M|MM:
> %(trad_capable_cpp) %(cpp_options) %(cpp_debug_options)}  %{!E:%{!M:
> %{!MM:  %{traditional|ftraditional:%eGNU C no longer
> supports -traditional without -E}   %{!combine:\t  %{sa"...)
> at ../../gcc/gcc.c:4436
> #8  0x0805654e in main (argc=36, argv=0xafc05dc4) at ../../gcc/gcc.c:6684

Ok looks like this is not a heisenbug, I left the gcc bootstrap going on and 
it took 4+ hours to compile insn-attrtab.c on this machine which looks really 
bad as it takes 2-3 minutes on my laptop.

Any idea where to look?

Regards,
ismail

-- 
Faith is believing what you know isn't so -- Mark Twain

Re: svn trunk reaches nearly 1 GiB!!! That massive!!!

[Ismail Dönmez]

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 solution to reduce this massive quantity
> for the most recent part of the trunk of the tree instead of full trunk?

git clone --depth 100 git://git.infradead.org/gcc.git

should give around ~50mb repository with usable trunk. This is all thanks to 
Bernardo Innocenti for setting up an up-to-date gcc git repo.

P.S: Please cut down on the usage of exclamation mark.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Git and GCC

[Ismail Dönmez]

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 --aggressive --prune.  Two hours
> later, it finished.
> The final size after this is 1.5 gig for all of the history of gcc for
> just trunk.
>
> [EMAIL PROTECTED]:/compilerstuff/gitgcc/gccrepo/.git/objects/pack$ ls -trl
> total 1568899
> -r--r--r-- 1 dberlin dberlin 1585972834 2007-12-05 14:01
> pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.pack
> -r--r--r-- 1 dberlin dberlin   19008488 2007-12-05 14:01
> pack-cd328fcf0bd673d8f2f72c42fbe67da64cbcd218.idx
>
> This is 3x bigger than hg *and* hg doesn't require me to waste my life
> repacking every so often.
> The hg operations run roughly as fast as the git ones

I think this (gcc HG repo) is very good but only problem is its not always in 
sync with SVN, it would really rock if a post svn commit hook would sync hg 
repo.

Thanks for doing this anyhow.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Git and GCC

[Ismail Dönmez]

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 to be resolved.

Lets be fair about this, Ollie Wild already sent a mail about git-svn disk 
usage and there is no concrete solution yet, though it seems the bottleneck 
is known.

Regards,
ismail


-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Git and GCC

[Ismail Dönmez]

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[*]. Has anyone tried? Is there any problem with it?
>
> [*] You have currently an obvious advantage here.

Last time I tried SVK it was slow and buggy. I wouldn't recommend it.

/ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Objective-C 2.0 in GCC

[Ismail Dönmez]

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 the current state?
>
> I hope to be able to contribute them in the next year, but exactly
> when remains uncertain.  I hope to know more about timing toward the
> front of next year.  Sorry I don't have anything more specific to say.

Any schedule for fixing Obj-C++ regressions on mainline?

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: Objective-C 2.0 in GCC

[Ismail Dönmez]

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...

We were talking about it the other day and its mentioned some regressions 
exist since the introduction of Obj-C++ support. Anyway hope you resolve 
non-technical issues without much sacrifise.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: -Wparentheses lumps too much together

[Ismail Dönmez]

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 find were many examples of people rototilling perfectly fine
> > code, "improving" it by adding unneeded parenthesis specifically so that
> > it would compile cleanly with -Wall.  I think that's a shame: a waste of
> > effort at best.
> >
> > I ask you, please, to consider splitting advice about operator precedence
> > from advice about mismatched if/else branches, and to exclude advice
> > about making sure && is parenthesized ahead of || from -Wall.  -Wall is
> > the standard for "good, clean code" in many projects.  This warning
> > doesn't belong there.
>
> For what it is worth, I completely agree with everything you have said
> here. This warning oversteps the bounds of what -Wall should do, and
> forces people to change perfectly good, clean code. Operator
> precedence is an important concept that any C or C++ programmer should
> know, and we're not helping anyone by pretending that programmer's
> won't understand this concept.
>
> We should certainly remove the warning from -Wall, and perhaps remove
> it entirely.

Agreed, for example it has lots of useless warnings when compiling ffmpeg.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

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.e+00   0x0.p+0
 should be:   1.57079637050628662109e+00   0x1.921fb600p+0
 difference:  1.57079637050628662109e+00   0x1.921fb600p+0
 ulp   :  13176795.
 max.ulp   :  0.

All of the imaginary part checks fail, with the help of GFortran maintainers 
we identified 2 testcases which fail with glibc 2.7 when compiled with gcc 
4.3 trunk [0] .

This problem also causes 32 unexpected failures on gfortran regression tests. 
So I wonder if you guys can help me debug this, I checked out libc sources 
but its mostly assembly stuff for math functions. Maybe Jakub has an idea, 
not sure.

Any help/comment appreciated.

[0] http://sourceware.org/bugzilla/show_bug.cgi?id=5490

Regards,
ismail


-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

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 are all similar :
>
> Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i
> Result:
>  is:  0.e+00   0x0.p+0
>  should be:   1.57079637050628662109e+00   0x1.921fb600p+0
>  difference:  1.57079637050628662109e+00   0x1.921fb600p+0
>  ulp   :  13176795.
>  max.ulp   :  0.

All these failures are gone when glibc is compiled with -O2 instead of -O3 but 
there are still 4 regressions :

math/test-ildoubl

Usual math problem :

testing long double (inline functions)
Failure: Test: expm1 (1) == M_El - 1.0
Result:
 is:  1.71828182845904523532e+00   0xd.bf0a8b1457695350p-3
 should be:   1.71828182845904523543e+00   0xd.bf0a8b1457695360p-3
 difference:  1.08420217248550443401e-19   0x8.p-66
 ulp   :  1.
 max.ulp   :  0.
Maximal error of `expm1'
 is  : 1 ulp
 accepted: 0 ulp

libio/tst-fopenloc2
libio/tst-fopenloc

These two seems to be a new gcc regression, they crash when compiled with gcc 
trunk.

elf/check-localplt

These seems to be less harmful, shows memalign is missing from expected 
output.


Any ideas appreciated.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

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 same 
commit seems to be the cause for PR34465 .

[0] http://gcc.gnu.org/viewcvs?view=rev&revision=130788

Regards,
ismail


-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

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 are all similar :
>
> Failure: Test: Imaginary part of: cacosh (-0 + 0 i) == 0.0 + pi/2 i
> Result:
>  is:  0.e+00   0x0.p+0
>  should be:   1.57079637050628662109e+00   0x1.921fb600p+0
>  difference:  1.57079637050628662109e+00   0x1.921fb600p+0
>  ulp   :  13176795.
>  max.ulp   :  0.

Replying to myself once again, these failures are due to -fgcse-after-reload 
flag, -O3 -fno-gcse-after-reload cures this. Any tips on how to debug this?

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.

Re: glibc 2.7 complex functions are possibly miscompiled by gcc 4.3 trunk

[Ismail Dönmez]

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 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.e+00   0x0.p+0
> > >  should be:   1.57079637050628662109e+00   0x1.921fb600p+0
> > >  difference:  1.57079637050628662109e+00   0x1.921fb600p+0
> > >  ulp   :  13176795.
> > >  max.ulp   :  0.
> >
> > Replying to myself once again, these failures are due to
> > -fgcse-after-reload flag, -O3 -fno-gcse-after-reload cures this. Any tips
> > on how to debug this?
>
> Generic advice to start: compile with -da to get all the RTL dump
> files.  Compare the dump files immediately before and after
> gcse-after-reload and see what changed.  Set breakpoints on
> validate_change or make_insn_raw as appropriate for the changes.  Walk
> up the stack and see what the code is doing.  The file in question is
> postreload-gcse.c, which is relatively self-contained.
>
> Of course it is moderately likely that the bug is not in
> gcse-after-reload, and is in some other pass generating incorrect
> information.  Still, finding the problem in gcse-after-reload is a
> good start.

Thanks I'll try, this is all new to me so its rather likely to be slow 
progress.

Regards,
ismail

-- 
Never learn by your mistakes, if you do you may never dare to try again.