Re: [PATCH] Use lwsync in PowerPC sync_* builtins
David Edelsohn wrote: > On Wed, Sep 3, 2008 at 6:53 PM, Anton Blanchard <[EMAIL PROTECTED]> wrote: >> The only thing lwsync wont order is a store followed by a load. Since >> the lwsync will always be paired with a store (the stwcx), we will order >> all accesses before it and provide a release barrier. > > Anton, > > My one other concern is developers using the builtins for applications on > embedded PowerPC processors. lwsync will not order accesses to device > memory space, AFAICT. Don't you need eieio+sync for that? GCC does not generate the eieio now. Paolo
Re: Warnings when building the Ada f-e
Duncan Sands wrote: Building gcc from svn today I see the following: prj-nmsc.adb: In function ‘Prj.Nmsc.Check_Naming_Schemes’: prj-nmsc.adb:3272: warning: ‘Casing’ may be used uninitialized in this function ... g-socket.adb: In function ‘GNAT.SOCKETS.SEND_SOCKET’: g-socket.adb:1786: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.RECEIVE_SOCKET’: g-socket.adb:1586: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.GET_SOCKET_NAME’: g-socket.adb:1001: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.CONNECT_SOCKET’: g-socket.adb:623: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.CONNECT_SOCKET’: g-socket.adb:655: warning: ‘REQ’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.BIND_SOCKET’: g-socket.adb:396: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.ACCEPT_SOCKET’: g-socket.adb:277: warning: ‘SIN’ is used uninitialized in this function g-socket.adb: In function ‘GNAT.SOCKETS.GET_PEER_NAME’: g-socket.adb:929: warning: ‘SIN’ is used uninitialized in this function ... a-strmap.adb: In function ‘Ada.Strings.Maps.To_Set’: a-strmap.adb:269: warning: ‘Result’ is used uninitialized in this function a-strmap.adb: In function ‘Ada.Strings.Maps.To_Set’: a-strmap.adb:285: warning: ‘Result’ is used uninitialized in this function ... g-comlin.adb: In function ‘GNAT.COMMAND_LINE.FIND_LONGEST_MATCHING_SWITCH’: g-comlin.adb:96: warning: ‘PARAM’ may be used uninitialized in this function g-comlin.adb:96: note: ‘PARAM’ was declared here This is x86_64-unknown-linux-gnu. Ciao, Duncan. the a-strmap warning is junk the g-comlin warning is at least missing documentation to be looked at ...
build failed with gcc trunk on cygwin host
Hello, I am trying to build the gcc tools on cygwin host. But the build failed with below errors: $ gcc -I../../../trunk/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings -Wstr ict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-att ribute -Wcast-qual -pedantic -Wno-long-long -I../../../trunk/libdecnumber -I. -c ../../../trunk/libdecnumber/dpd/decimal128.c In file included from ../../../trunk/libdecnumber/decNumber.h:42, from ../../../trunk/libdecnumber/dpd/decimal128.c:47: ../../../trunk/libdecnumber/decContext.h:59:61: gstdint.h: No such file or directory $ gcc -v Thread model: posix gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) === Could you please advise the reason for build for the above build fail. Thank you. Thanks Swami
libgomp testsuite failure on trunk revision 139927 for i686-pc-linux-gnu and x86_64-unknown-linux-gnu -m32
recently I see this failures: Running target unix/-m32 FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer execution test FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test === libgomp Summary for unix/-m32 === # of expected passes2286 # of unexpected failures3 Additionally glibc detects an error: *** glibc detected *** ./vla7.exe: munmap_chunk(): invalid pointer: 0x08058820 *** -- Mit freundlichen Grüßen / Best Regards Dipl.-Ing. Rainer Emrich Dept. Manager IT/Softwareentwicklung TECOSIM Technische Simulation GmbH Ferdinand-Stuttmann-Straße 15 D-65428 Rüsselsheim Phone +49 (0) 6142 8272-330 Fax+49 (0) 6142 8272-249 Mobile +49 (0) 163 5694920 www.tecosim.com best partner for simulation _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ TECOSIM Technische Simulation GmbH, Rüsselsheim Firmensitz: Ferdinand-Stuttmann-Straße 15, 65428 Rüsselsheim Registergericht: Amtsgericht Darmstadt, HRB 83704 Geschäftsführer: Udo Jankowski, Jürgen Veith
Re: [PATCH] Use lwsync in PowerPC sync_* builtins
David Daney wrote: On Wed, Sep 3, 2008 at 6:09 PM, David Edelsohn <[EMAIL PROTECTED]> wrote: On Wed, Sep 3, 2008 at 6:53 PM, Anton Blanchard <[EMAIL PROTECTED]> wrote: The only thing lwsync wont order is a store followed by a load. Since the lwsync will always be paired with a store (the stwcx), we will order all accesses before it and provide a release barrier. Anton, My one other concern is developers using the builtins for applications on embedded PowerPC processors. lwsync will not order accesses to device memory space, AFAICT. I do not know if developers would rely on GCC builtins in that context and assume it implements the correct semantics. Otherwise, I agree that the memory barrier operations probably can use lwsync. Would it be possible to have a conservative default and use a more optimal form based on a specific CPU specified by -mcpu=? I was thinking of doing something similar on MIPS where there are similar issues. Another related issue is that psim in gdb does not currently support the lwsync instruction so any code generated using it would fail there. Since this is used as the test platform for the embedded gcc targets (at least powerpc-elf and powerpc-rtems) if gcc is going to generate this instruction, the simulator needs to support it or there will be lots of failures. David Daney -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Re: [PATCH] Use lwsync in PowerPC sync_* builtins
On Thu, Sep 4, 2008 at 8:31 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote: > Another related issue is that psim in gdb does not currently > support the lwsync instruction so any code generated using it > would fail there. Since this is used as the test platform for > the embedded gcc targets (at least powerpc-elf and powerpc-rtems) > if gcc is going to generate this instruction, the simulator > needs to support it or there will be lots of failures. Joel, That is unfortunate, but it is a long-term, known problem with PSIM. Someone maintaining PSIM needs to update it. At worst, just make lwsync an alias for sync. It does not make sense to delay improving performance because a simulator is far out of date. You also can make a private change to GCC rs6000 port sources to set TARGET_NO_LWSYNC so that sync is generated instead of lwsync. David
Re: [PATCH] Use lwsync in PowerPC sync_* builtins
David Edelsohn wrote: On Thu, Sep 4, 2008 at 8:31 AM, Joel Sherrill <[EMAIL PROTECTED]> wrote: Another related issue is that psim in gdb does not currently support the lwsync instruction so any code generated using it would fail there. Since this is used as the test platform for the embedded gcc targets (at least powerpc-elf and powerpc-rtems) if gcc is going to generate this instruction, the simulator needs to support it or there will be lots of failures. Joel, That is unfortunate, but it is a long-term, known problem with PSIM. Someone maintaining PSIM needs to update it. At worst, just make lwsync an alias for sync. Honestly the psim code is very cryptic in this area. I would add it if I could figure out how. :( It does not make sense to delay improving performance because a simulator is far out of date. No I would never say that it did either. You also can make a private change to GCC rs6000 port sources to set TARGET_NO_LWSYNC so that sync is generated instead of lwsync. That's what we do now but I would like to not have to do that. David -- Joel Sherrill, Ph.D. Director of Research & Development [EMAIL PROTECTED]On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
Bootstrap failure in libstdc++ on i386-pc-solaris2.10
Hi.
My last successful build was from yesterday morning. After the large
libstdc++ patch by Chris Fairles landed the builds have failed with the
following error:
In file included from
/export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
/export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:
In constructor 'std::once_flag::once_flag()':
/export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
make[4]: *** [mutex.lo] Error 1
Art Haas
Re: libgomp testsuite failure on trunk revision 139927 for i686-pc-linux-gnu and x86_64-unknown-linux-gnu -m32
On Thu, Sep 4, 2008 at 5:29 AM, Rainer Emrich <[EMAIL PROTECTED]> wrote: > recently I see this failures: > > Running target unix/-m32 > FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer execution test > FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-loops > execution test > FAIL: libgomp.fortran/vla7.f90 -O3 -fomit-frame-pointer -funroll-all-loops > -finline-functions execution test It is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37296 and fixed by revision 139948. H.J. ---
Re: Bootstrap failure in libstdc++ on i386-pc-solaris2.10
On Thu, Sep 4, 2008 at 9:30 AM, Art Haas <[EMAIL PROTECTED]> wrote:
> Hi.
>
> My last successful build was from yesterday morning. After the large
> libstdc++ patch by Chris Fairles landed the builds have failed with the
> following error:
>
> In file included from
> /export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:
> In constructor 'std::once_flag::once_flag()':
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
> error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
> make[4]: *** [mutex.lo] Error 1
>
> Art Haas
>
Can you try the attached patch?
Thanks,
Chris
Index: include/std/mutex
===
--- include/std/mutex (revision 139984)
+++ include/std/mutex (working copy)
@@ -615,8 +615,10 @@
typedef __gthread_once_t __native_type;
once_flag()
-: _M_once(__GTHREAD_ONCE_INIT)
-{ }
+{
+ __gthread_once_t __tmp = __GTHREAD_ONCE_INIT;
+ _M_once = __tmp;
+}
once_flag(const once_flag&) = delete;
once_flag& operator=(const once_flag&) = delete;
Re: Bootstrap failure in libstdc++ on i386-pc-solaris2.10
On Thu, Sep 4, 2008 at 9:41 AM, Chris Fairles <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 4, 2008 at 9:30 AM, Art Haas <[EMAIL PROTECTED]> wrote:
>> Hi.
>>
>> My last successful build was from yesterday morning. After the large
>> libstdc++ patch by Chris Fairles landed the builds have failed with the
>> following error:
>>
>> In file included from
>> /export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
>> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:
>> In constructor 'std::once_flag::once_flag()':
>> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
>> error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
>> make[4]: *** [mutex.lo] Error 1
>>
>> Art Haas
>>
>
> Can you try the attached patch?
>
> Thanks,
> Chris
>
Also posting to libstdc++ list.
Chris
Re: [PATCH] Use lwsync in PowerPC sync_* builtins
On Thu, Sep 04, 2008 at 09:04:30AM -0400, David Edelsohn wrote: > That is unfortunate, but it is a long-term, known problem with PSIM. Someone > maintaining PSIM needs to update it. Also unfortunately, there is no one maintaining PSIM. It's shipped with GDB, but I consider that only a convenience for the implementation of 'target sim'; it's really an independent project. -- Daniel Jacobowitz CodeSourcery
Re: Bootstrap failure in libstdc++ on i386-pc-solaris2.10
On Thu, 2008-09-04 at 13:41, Chris Fairles wrote:
> On Thu, Sep 4, 2008 at 9:30 AM, Art Haas <[EMAIL PROTECTED]>
> wrote:
> > Hi.
> >
> > My last successful build was from yesterday morning. After the large
> > libstdc++ patch by Chris Fairles landed the builds have failed with
> the
> > following error:
> >
> > In file included from
> > /export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
> >
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:
> In constructor 'std::once_flag::once_flag()':
> >
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
> error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
> > make[4]: *** [mutex.lo] Error 1
> >
> > Art Haas
> >
>
> Can you try the attached patch?
>
> Thanks,
> Chris
I applied the patch, and just typed 'make' in this mornings build
directory so the build would skip the stages and just jump to the
libstdc++ stuff. The patch worked, libstdc++ linked, and the build
finished.
Thanks!
Art Haas
Re: Bootstrap failure in libstdc++ on i386-pc-solaris2.10
> Hi.
>
> My last successful build was from yesterday morning. After the large
> libstdc++ patch by Chris Fairles landed the builds have failed with the
> following error:
>
> In file included from
> /export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:
> In constructor 'std::once_flag::once_flag()':
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
> error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
> make[4]: *** [mutex.lo] Error 1
What rev of the GCC code are you working with here?
You lost me ... I have no issues with GCC 4.3.2.
Dennis
Re: Bootstrap failure in libstdc++ on i386-pc-solaris2.10
On Thu, 2008-09-04 at 13:44, Dennis Clarke wrote:
> > Hi.
> >
> > My last successful build was from yesterday morning. After the large
> > libstdc++ patch by Chris Fairles landed the builds have failed with
> the
> > following error:
> >
> > In file included from
> > /export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
> >
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:
> > In constructor 'std::once_flag::once_flag()':
> >
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
> > error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
> > make[4]: *** [mutex.lo] Error 1
>
> What rev of the GCC code are you working with here?
>
> You lost me ... I have no issues with GCC 4.3.2.
>
> Dennis
I'm building the GCC trunk, and I've locally applied the patches by
Rainer Orth to fix an issue my builds stumbled over back in July.
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01981.html
Since I'm posting to the mailing list, let me 'ping' this patch.
Art Haas
Re: Bootstrap failure in libstdc++ on i386-pc-solaris2.10
>
> On Thu, 2008-09-04 at 13:44, Dennis Clarke wrote:
>> > Hi.
>> >
>> > My last successful build was from yesterday morning. After the large
>> > libstdc++ patch by Chris Fairles landed the builds have failed with
>> the
>> > following error:
>> >
>> > In file included from
>> > /export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
>> >
>> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:
>> > In constructor 'std::once_flag::once_flag()':
>> >
>> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
>> > error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
>> > make[4]: *** [mutex.lo] Error 1
>>
>> What rev of the GCC code are you working with here?
>>
>> You lost me ... I have no issues with GCC 4.3.2.
>>
>> Dennis
>
> I'm building the GCC trunk, and I've locally applied the patches by
> Rainer Orth to fix an issue my builds stumbled over back in July.
>
> http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01981.html
okay .. I see. What did you mena by "no baseline to compare against"?
Did you need to test this on Solaris 10 FCS ( build 74L2a ) or did you
mean something else?
Dennis Clarke
Re: Bootstrap failure in libstdc++ on i386-pc-solaris2.10
On Thu, 2008-09-04 at 13:59, Dennis Clarke wrote:
> >
> > On Thu, 2008-09-04 at 13:44, Dennis Clarke wrote:
> >> > Hi.
> >> >
> >> > My last successful build was from yesterday morning. After the
> large
> >> > libstdc++ patch by Chris Fairles landed the builds have failed
> with
> >> the
> >> > following error:
> >> >
> >> > In file included from
> >> > /export/home/arth/gnu/gcc.git/libstdc++-v3/src/mutex.cc:30:
> >> >
> >>
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:
> >> > In constructor 'std::once_flag::once_flag()':
> >> >
> >>
> /export/home/arth/gnu/gcc-0904/i386-pc-solaris2.10/libstdc++-v3/include/mutex:618:
> >> > error: could not convert '{{0, 0, 0, 0}}' to '__gthread_once_t'
> >> > make[4]: *** [mutex.lo] Error 1
> >>
> >> What rev of the GCC code are you working with here?
> >>
> >> You lost me ... I have no issues with GCC 4.3.2.
> >>
> >> Dennis
> >
> > I'm building the GCC trunk, and I've locally applied the patches by
> > Rainer Orth to fix an issue my builds stumbled over back in July.
> >
> > http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01981.html
>
> okay .. I see. What did you mena by "no baseline to compare against"?
>
> Did you need to test this on Solaris 10 FCS ( build 74L2a ) or did you
> mean something else?
>
>
> Dennis Clarke
Maybe he meant he didn't have an earlier build to test against, I'm not
sure. Without the patch, though, my builds were failing. BTW, I'm
building the i386-pc-solaris2.10 binary on an 11/06 Solaris 10 release,
and the sparc-sun-solaris2.10 build is on the 11/06 Solaris 10 release
as well.
Art Haas
built-in-setjmp failure.
Hello,
In our GCC porting (gcc 4.3.1), I am facing a problem with
built-in-setjmp test, which failed from -O2. After spending quite some
time on it, I figured out what happens, but not sure what is the best
way to fix it. The problem is with __builtin_setjmp_receiver.
In built-in-setjmp.c.132r.expand
;; __builtin_setjmp_receiver (&)
(insn 62 61 63
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (use (reg/f:SI 55 r55)) -1 (nil))
(insn 63 62 64
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (clobber (reg:SI 27 r27)) -1 (nil))
(insn 64 63 65
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (set (reg/f:SI 79 virtual-stack-vars)
(reg/f:SI 55 r55)) -1 (nil))
(insn 65 64 66
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (clobber (reg/f:SI 55 r55)) -1 (nil))
(insn 66 65 0
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (asm_input/v ("") 0) -1 (nil))
After replacing virtual register with real ones, it is tranformed to
following code (builtin-setjmp.c.137r.vregs). R55 is our frame pointer
and we have #define STARTING_FRAME_OFFSET -128
(insn 62 61 63 6
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (use (reg/f:SI 55 r55)) -1 (nil))
(insn 63 62 157 6
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (clobber (reg:SI 27 r27)) -1 (nil))
(insn 157 63 65 6
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (set (reg/f:SI 55 r55)
(plus:SI (reg/f:SI 55 r55)
(const_int 128 [0x80]))) -1 (nil))
(insn 65 157 66 6
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (clobber (reg/f:SI 55 r55)) -1 (nil))
(insn 66 65 67 6
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (asm_input/v ("") 0) -1 (nil))
Now the problem is that insn 157 defines r55, and the following insn 65
clobbers r55 as well. Therefore, in the dead code elimination pass,
insn 157 is optimized away (built-in-setjmp.162r.dce) and produces wrong
results.
(insn 62 61 63 4
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (use (reg/f:SI 55 r55)) -1 (nil))
(insn 63 62 65 4
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (clobber (reg:SI 27 r27)) -1
(expr_list:REG_UNUSED (reg:SI 27 r27)
(nil)))
(insn 65 63 66 4
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (clobber (reg/f:SI 55 r55)) -1 (nil))
(insn 66 65 114 4
/projects/firepath/tools/work/bmei/gcc-head/src/gcc/testsuite/gcc.c-tort
ure/execute/built-in-setjmp.c:21 (asm_input/v ("") 0) -1 (nil))
I checked how the __builtin_setjmp_receiver is expanded in builtins.c:
...
#ifdef HAVE_nonlocal_goto
if (! HAVE_nonlocal_goto)
#endif
{
emit_move_insn (virtual_stack_vars_rtx, hard_frame_pointer_rtx);
/* This might change the hard frame pointer in ways that aren't
apparent to early optimization passes, so force a clobber. */
emit_insn (gen_rtx_CLOBBER (VOIDmode, hard_frame_pointer_rtx));
< clobber
}
...
It always produces the clobber after moving hard frame pointer to
virtual_stack_vars_rtx. Commenting out this statement make test work
correctly and doesn't effect others. However, I don't want to modify GCC
source code itself. I guess other targets may face similar issue. Is
this a potential bug for GCC or is there any way to overcome it just by
changing my porting?
I did a search on the mailing list, and found the following thread
reported a very similar issue. Unfortunately, it didn't have follow-up
about solution.
http://gcc.gnu.org/ml/gcc/2008-03/msg00932.html
Cheers,
Bingfeng Mei
Broadcom UK
Re: build failed with gcc trunk on cygwin host
"M R Swami Reddy" <[EMAIL PROTECTED]> writes: > I am trying to build the gcc tools on cygwin host. But the build > failed with below errors: > > $ gcc -I../../../trunk/libdecnumber -I. -g -O2 -W -Wall -Wwrite-strings > -Wstr > ict-prototypes -Wmissing-prototypes -Wold-style-definition > -Wmissing-format-att > ribute -Wcast-qual -pedantic -Wno-long-long -I../../../trunk/libdecnumber -I. > -c ../../../trunk/libdecnumber/dpd/decimal128.c > In file included from ../../../trunk/libdecnumber/decNumber.h:42, > from ../../../trunk/libdecnumber/dpd/decimal128.c:47: > ../../../trunk/libdecnumber/decContext.h:59:61: > gstdint.h: No such file or directory > > $ gcc -v > Thread model: posix > gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125) > === > > Could you please advise the reason for build for the above build fail. Thank > you. Please never send messages to both gcc@gcc.gnu.org and [EMAIL PROTECTED] This message is appropriate only for gcc-help. Please take any followups only to gcc-help. Thanks. I would guess that you have run ./configure rather than running the configure script in a different empty directory as prescribed by the installation instructions. Ian
two more build results for gcc 4.3.2
I located a couple of old machines to try, so I have two more successful build reports, and one failure (though don't worry about the failure yet). First one (includes C, C++, ObjC, Fortran, and Java) i686-pc-linux-gnu on a RHEL 3 system. boot compiler: gcc 3.3.6 (FSF release) kernel: 2.4.21-32.EL (from Red Hat) glibc: 2.3.2-95.33 (from Red Hat) binutils: 2.17 (FSF release) GMP: 4.1.2-5 (from Red Hat) MPFR: 2.3.1 Results: http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00304.html The failures and noise are evidently due to the ancient glibc. Second one (includes C, C++, ObjC, and Fortran) hppa2.0w-hp-hpux11.00 This is an HP 9000/800/L1000-36 Bootstrapped with gcc 3.2.3. as is from binutils-2.18 (FSF), native linker gmp is 4.2.2 (FSF) mpfr is 2.3.1 (FSF) Results: http://gcc.gnu.org/ml/gcc-testresults/2008-09/msg00306.html No issues building GCC, I did have to turn off -Werror in a couple of places to get binutils 2.18 to build with gcc. I also found an ia64 box running Red Hat Advanced Workstation 2.1. Yes, I know, really old, but I can't change it. I tried a build using Bootstrap compiler is FSF gcc 3.2.3 kernel: kernel-2.4.18-e.12smp (from Red Hat) glibc: 2.2.4-29.2 (from Red Hat) binutils: 2.18 (FSF) gmp: 4.2.2 (FSF) mpfr: 2.3.1 (FSF) but the bootstrap died. gcc itself three-stage bootstrapped OK, then died during the multilib configuration for libgcc. It might just have been an issue with the shared library path, now that I look at it; I'll re-check.
Re: two more build results for gcc 4.3.2
On Thu, Sep 04, 2008 at 11:12:59AM -0700, Joe Buck wrote: > I also found an ia64 box running Red Hat Advanced Workstation 2.1. > Yes, I know, really old, but I can't change it. I tried a build... > but the bootstrap died. I think the issue was that the --with-gmp and --with-mpfr directories weren't in LD_LIBRARY_PATH. I'm re-trying. If that's the issue, I think that it should automatically be taken care of; the configure process can determine that it's picking up shared libraries that aren't on the default path and make sure that things work anyway.
Re: IRA copy heuristics
Richard Sandiford <[EMAIL PROTECTED]> writes: > Vladimir Makarov <[EMAIL PROTECTED]> writes: >> Richard Sandiford wrote: >>> But as I said to HJ, I'm happy to apply the DF patch in isolation, >>> as long as we accept that the benefit of fixing a correctness >>> regression outweighs the potential performance regression. >>> >> Sure, regression is more important. Therefore even if you submit only >> one (reverse BB traverse) patch, it is ok for me. >> >> As I wrote I am going to look at the second patch. I have feeling that >> even without the second patch, there will be no performance regression. >> I think that my latest patches (some of them are not in the mainline >> yet) removed IRA instability toward allocno ordering. I just need time >> to make sure about this. > > Great! Thanks. I'll test overnight and submit tomorrow if everything > goes OK. Bootstrapped & regression-tested on x86_64-linux-gnu, with the following FAILs fixed: WARNING: program timed out. FAIL: g++.old-deja/g++.eh/ia64-1.C execution test FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test Applied as 133993. Thanks Vlad for the review, and thanks HJ for noticing that it fixed the above x86_64 regressions. Richard
Re: two more build results for gcc 4.3.2
On Thu, Sep 04, 2008 at 11:12:59AM -0700, Joe Buck wrote: > > I also found an ia64 box running Red Hat Advanced Workstation 2.1. > > Yes, I know, really old, but I can't change it. I tried a build... > > but the bootstrap died. On Thu, Sep 04, 2008 at 11:37:47AM -0700, Joe Buck wrote: > I think the issue was that the --with-gmp and --with-mpfr directories > weren't in LD_LIBRARY_PATH. I'm re-trying. If that's the issue, > I think that it should automatically be taken care of; the configure > process can determine that it's picking up shared libraries that > aren't on the default path and make sure that things work anyway. So I tried that, and it didn't help. It dies with mkdir -p -- ia64-unknown-linux-gnu/libgcc Checking multilib configuration for libgcc... Configuring stage 1 in ia64-unknown-linux-gnu/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c checking for gawk... gawk checking build system type... ia64-unknown-linux-gnu checking host system type... ia64-unknown-linux-gnu checking for ia64-unknown-linux-gnu-ar... ar checking for ia64-unknown-linux-gnu-lipo... lipo checking for ia64-unknown-linux-gnu-nm... /remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/nm checking for ia64-unknown-linux-gnu-ranlib... ranlib checking for ia64-unknown-linux-gnu-strip... strip checking whether ln -s works... yes checking for ia64-unknown-linux-gnu-gcc... /remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/xgcc -B/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/bin/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/lib/ -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/include -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/sys-include checking for suffix of object files... configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. But ia64-unknown-linux-gnu/libgcc/config.log doesn't have any useful details. It has CC='/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/xgcc -B/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/bin/ -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/lib/ -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/include -isystem /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/sys-include' and ends with - #define PACKAGE_BUGREPORT "" #define PACKAGE_NAME "GNU C Runtime Library" #define PACKAGE_STRING "GNU C Runtime Library 1.0" #define PACKAGE_TARNAME "libgcc" #define PACKAGE_VERSION "1.0" configure: exit 1 - and the "exit 1" is the only sign that something is wrong.
Re: two more build results for gcc 4.3.2
Joe Buck <[EMAIL PROTECTED]> writes: > But ia64-unknown-linux-gnu/libgcc/config.log doesn't have any useful > details. It has > > CC='/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/xgcc > -B/remote/atg5/jbuck/gcc-4.3.2-ia64build/./gcc/ > -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/bin/ > -B/u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/lib/ -isystem > /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/include -isystem > /u/jbuck/cvs.ia64/4.3.2/ia64-unknown-linux-gnu/sys-include' > > and ends with > > - > #define PACKAGE_BUGREPORT "" > #define PACKAGE_NAME "GNU C Runtime Library" > #define PACKAGE_STRING "GNU C Runtime Library 1.0" > #define PACKAGE_TARNAME "libgcc" > #define PACKAGE_VERSION "1.0" > > configure: exit 1 > - > > and the "exit 1" is the only sign that something is wrong. These days autoconf likes to dump a whole bunch of cruft at the end of config.log. You have to look above all the cruft, which is usually most of the file, to find the actual failing test case. Ian
Re: two more build results for gcc 4.3.2
[ see parents for my build problems ] On Thu, Sep 04, 2008 at 02:00:11PM -0700, Ian Lance Taylor wrote: > These days autoconf likes to dump a whole bunch of cruft at the end of > config.log. You have to look above all the cruft, which is usually > most of the file, to find the actual failing test case. Sure enough, it's the shared library; it appears that my attempt to set the path had a typo. That's what I thought the issue was. How embarrassing, sorry for the noise.
GCC Plugins (again)
Hi all, Every now and then I poke my head into this list to see if there is any more progress on the GCC Plugin branch issue. In particular I don't want to give up on this feature as it will be enormously useful for my open source project EDoc++. In the past, we have had a lot of discussion about the feature, but the end result has been that RMS is opposed to it so nothing will be done about it because he has the power. Can anyone suggest where to go from here? Preferably, I wish we could convince RMS that this is a good move forward. Barring that the only solution I can think of is to create a "fork" of GCC. Where for every GCC release, I provide a patched release with plugin support. The issue then would be getting the various distros to use the plugin variant rather than the "official" one (Which could be quite difficult). The following wiki page (not sure who created it) is a decent summary of the past discussion on this issue: http://gcc.gnu.org/wiki/GCC_Plugins Thanks, Brendon.
Re: GCC Plugins (again)
On Fri, Sep 05, 2008 at 08:11:34AM +1000, Brendon Costa wrote: > Every now and then I poke my head into this list to see if there is any > more progress on the GCC Plugin branch issue. In particular I don't want > to give up on this feature as it will be enormously useful for my open > source project EDoc++. > > In the past, we have had a lot of discussion about the feature, but the > end result has been that RMS is opposed to it so nothing will be done > about it because he has the power. Some progress has been made on that issue, the idea is to use some new legal language to give the FSF the assurance that it needs. Roughly, the GPL exception for the use of the runtime support libraries wouldn't apply for those who use proprietary plugins to generate the code. The first draft of the legal language to do this job had some major problems, but now there's a new draft. Anything that has lawyers involved takes a while, but I do think it's going to work out. > Preferably, I wish we could convince RMS that this is a good move > forward. Barring that the only solution I can think of is to create a > "fork" of GCC. Where for every GCC release, I provide a patched release > with plugin support. The issue then would be getting the various distros > to use the plugin variant rather than the "official" one (Which could be > quite difficult). RMS has already been convinced, and now the holdup is to complete the legalities and run it by the interested parties. Please be patient for a while longer. Design work can certainly proceed. Only those who want to license their plugin code in a way that is incompatible with GPLv3 are going to need to fork. The wiki page could use some work, but I'm hesitant to add anything that looks like a promise at this point.
gcc-4.3-20080904 is now available
Snapshot gcc-4.3-20080904 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080904/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 140011 You'll find: gcc-4.3-20080904.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080904.tar.bz2 C front end and core compiler gcc-ada-4.3-20080904.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080904.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080904.tar.bz2 C++ front end and runtime gcc-java-4.3-20080904.tar.bz2 Java front end and runtime gcc-objc-4.3-20080904.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080904.tar.bz2The GCC testsuite Diffs from 4.3-20080828 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: GCC Plugins (again)
> Plugins features. This addresses Richard Stallman's concerns, so he > no > longer objects to a Plugins feature. That is GREAT news!!! > We, the GCC community, are waiting for the advocates of Plugins to > reach > a consensus on a single plugins architecture and implement it. When > are the > people interested in this going to finish a robust implementation that > can be > merged into GCC? Any idea where i can go to have some involvement in this? It was a while ago that i checked out the plugin branch to look at and i am sure some things may have changed since then. I might have another look this weekend... Thanks, Brendon.
Re: IRA copy heuristics
Richard Sandiford wrote: Richard Sandiford <[EMAIL PROTECTED]> writes: Vladimir Makarov <[EMAIL PROTECTED]> writes: Richard Sandiford wrote: But as I said to HJ, I'm happy to apply the DF patch in isolation, as long as we accept that the benefit of fixing a correctness regression outweighs the potential performance regression. Sure, regression is more important. Therefore even if you submit only one (reverse BB traverse) patch, it is ok for me. As I wrote I am going to look at the second patch. I have feeling that even without the second patch, there will be no performance regression. I think that my latest patches (some of them are not in the mainline yet) removed IRA instability toward allocno ordering. I just need time to make sure about this. Great! Thanks. I'll test overnight and submit tomorrow if everything goes OK. Bootstrapped & regression-tested on x86_64-linux-gnu, with the following FAILs fixed: WARNING: program timed out. FAIL: g++.old-deja/g++.eh/ia64-1.C execution test FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test Applied as 133993. Thanks Vlad for the review, and thanks HJ for noticing that it fixed the above x86_64 regressions. Thanks, Richard. I was wrong the patch alone results in significant performance degradation. The SPECInt2000 is worse by 0.8% and SPECFP2000 by 1% (the worst degradation about %5 was found on mgrid) on x86 (Intel Core2 in 32-bit mode). I think the reason for this not in copies but in something else. I am going to investigate the problem when I have time. Meanwhile I am going to submit your second patch with an added comment. The patch permits gcc to generate the same quality code as before your first patch.
Re: IRA copy heuristics
On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote: > Meanwhile I am going to submit your second patch with an added > comment. The patch permits gcc to generate the same quality code as > before your first patch. Why? As Richard said before: "... it changes the heuristics _without any explanation of why this is necessary_. IMO, that's unacceptable for our shiny, new (and generally very nice) register allocator. And I think it's unacceptable even if it happens to fix a performance regression." The patch does not seem to have any justification other than it fixes the symptom. David
Re: IRA copy heuristics
On Thu, 2008-09-04 at 20:28 -0400, David Edelsohn wrote: > On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote: > > Meanwhile I am going to submit your second patch with an added > > comment. The patch permits gcc to generate the same quality code as > > before your first patch. > > Why? > > As Richard said before: > > "... it changes > the heuristics _without any explanation of why this is necessary_. > IMO, that's unacceptable for our shiny, new (and generally very nice) > register allocator. And I think it's unacceptable even if it happens > to fix a performance regression." I have to agree with Richard and David here. I find it troubling that allocation order affects performance by anything other than a small amount due to heuristic noise. It might be in the end there is a valid reason on why Richard's patch has a positive benefit, but until we know why, I'd rather wait. Peter
Re: IRA copy heuristics
Peter Bergner wrote: On Thu, 2008-09-04 at 20:28 -0400, David Edelsohn wrote: On Thu, Sep 4, 2008 at 7:39 PM, Vladimir Makarov <[EMAIL PROTECTED]> wrote: Meanwhile I am going to submit your second patch with an added comment. The patch permits gcc to generate the same quality code as before your first patch. Why? As Richard said before: "... it changes the heuristics _without any explanation of why this is necessary_. IMO, that's unacceptable for our shiny, new (and generally very nice) register allocator. And I think it's unacceptable even if it happens to fix a performance regression." I have to agree with Richard and David here. I find it troubling that allocation order affects performance by anything other than a small amount due to heuristic noise. It might be in the end there is a valid reason on why Richard's patch has a positive benefit, but until we know why, I'd rather wait. Peter Agreed. Let's at least have a reasonable explanation of why this is affecting performance so much. In theory, this kind of change ought to be in the noise. Jeff
New assert in haifa-sched.c
haifa-sched.c:
2302/* Let the target filter the search space. */
2303for (i = 1; i < ready->n_ready; i++)
2304 if (!ready_try[i])
2305{
2306 insn = ready_element (ready, i);
2307
2308 gcc_assert (INSN_CODE (insn) >= 0
2309 || recog_memoized (insn) < 0);
I am hitting this assert with the Octeon pipeline patch. Isn't the check on
recog_memoized reversed? Or are we really asserting here that the insn has
either been recognized earlier or won't be recognized now either?!
Adam
