Re: request of copyright assignment form
On Sat, 8 Jul 2006, Gerald Pfeifer wrote: > On Fri, 7 Jul 2006, James E Wilson wrote: >> I thought it was the actual legal forms that weren't supposed to be on >> the web site, but that the questionnaire was OK. > I believe I recall we were not supposed to have either, but you raise > a good point. I will double check this with RMS, and if he agrees, I > will make sure to add the questionnaire (and buy Mike a drink next time > I meet him). I checked with RMS, and indeed also prefers the questionnaire itself not to be published on the web site. :-( He hinted that they are thinking about switching to web forms, which would be rather cool; I don't know how this is going to take, though. Gerald
Re: SPEC CPU 2006 and gcc
H. J. Lu wrote: Has anyone tried SPEC CPU 2006 with gcc mainline and 4.1 branch? Well, I'd like to order, but it is unclear from the online documentation whether I'm eligible for the educational / non-profit price. $ 800 is a bit too much - even for my most prominent hobby. Cheers, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/2006-01/msg0.html
Re: SPEC CPU 2006 and gcc
* Toon Moene: > Well, I'd like to order, but it is unclear from the online > documentation whether I'm eligible for the educational / non-profit > price. > > $ 800 is a bit too much - even for my most prominent hobby. I know someone who has received (or is about to receive) a license he probably doesn't need. I'm not sure if it is transferable, though.
Re: SPEC CPU 2006 and gcc
On Sun, 2006-09-03 at 19:26 +0200, Florian Weimer wrote: > * Toon Moene: > > > Well, I'd like to order, but it is unclear from the online > > documentation whether I'm eligible for the educational / non-profit > > price. > > > > $ 800 is a bit too much - even for my most prominent hobby. > > I know someone who has received (or is about to receive) a license he > probably doesn't need. I'm not sure if it is transferable, though. Also note that if you have a license for an older version of SPEC, you may be able to upgrade for less than the cost of a new license. IIRC that was the case many years ago jeff
Re: Many new ICEs in the libstdc++-v3 testsuite
On Sat, 2006-09-02 at 20:40 -0700, Andrew Pinski wrote: > On Fri, 2006-09-01 at 20:13 -0400, Andrew Pinski wrote: > > This was caused by: > > http://gcc.gnu.org/viewcvs?view=rev&revision=116623 > > And here is one reduced testcase which we just reject now but it is > valid code as far as I can tell: I filed this as PR 28942 so everyone can track the progress of this bug. Thanks, Andrew Pinski Adding Geoff to the CC because he also found the same problem: http://gcc.gnu.org/ml/gcc-regression/2006-09/msg2.html
Re: Many new ICEs in the libstdc++-v3 testsuite
Andrew Pinski wrote: On Sat, 2006-09-02 at 20:40 -0700, Andrew Pinski wrote: On Fri, 2006-09-01 at 20:13 -0400, Andrew Pinski wrote: This was caused by: http://gcc.gnu.org/viewcvs?view=rev&revision=116623 And here is one reduced testcase which we just reject now but it is valid code as far as I can tell: I filed this as PR 28942 so everyone can track the progress of this bug. Thanks Andrew, you are indeed helping much more than me, but really I'm absorbed by something else, sorry. Paolo.
Re: SPEC CPU 2006 and gcc
Florian Weimer wrote: * Toon Moene: Well, I'd like to order, but it is unclear from the online documentation whether I'm eligible for the educational / non-profit price. $ 800 is a bit too much - even for my most prominent hobby. I know someone who has received (or is about to receive) a license he probably doesn't need. I'm not sure if it is transferable, though. Thanks. It might help to stress that I'm only interested in getting the Fortran codes standard conforming. Obviously I'm not going to run the benchmarks for real on this 2 GHz AMD 64 Athlon laptop ... -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/2006-01/msg0.html
Re: GCC 4.3 Projects Page
Daniel Berlin wrote: On 9/1/06, Mark Mitchell <[EMAIL PROTECTED]> wrote: Joe Buck wrote: > On Fri, Sep 01, 2006 at 03:56:30PM -0700, Mark Mitchell wrote: >> Please add your project page to the bottom of: >> >> http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning > > BTW, that page provides a link to "SampleProjectPage" which does not exist. Thanks! I forgot which Wiki syntax I was using; that's now fixed. In order to make life even easier, i renamed the sample project page to end in Template. Thanks! -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: MyGCC and whole program static analysis
On Wednesday 30 August 2006 18:52, Basile STARYNKEVITCH wrote: > Le Wed, Aug 30, 2006 at 06:36:19PM +0200, basile écrivait/wrote: > > Maybe some of your are aware of MyGCC http://mygcc.free.fr/ which > > seems to be an extended GCC to add some kind of static analysis. > > > > I'm quite surprised that the mygcc page gives x86/linux binaries, but > > no source tarball of their compiler (this seems to me against the > > spirit of the GPL licence, but I am not a lawyer). > > My public apologies to MyGCC. There is a patch on > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01437.html but sadly the > http://mygcc.free.fr does not provide any link to it. > > It is sad to have to google to find their patch, it would be simpler > if they linked it (or even gave full source tarball). Basile, I apologize for the inconvenience, I agree with everybody that mygcc sources, although publicly available, were not as easy to get as they had to. It's just that in my view, the site was only distributing a pre-compiled snapshot of something going on in a (public) gcc development branch. So, I fixed all that today: - there is a link on the site to the proposed gcc patch - the full source archive is also available in the download page. Thank you for your interest, and for your announce about the very exciting starting GGCC project. Nic.
Re: gets is not too dangerous
On Thu, 2006-08-31 at 17:52 -0400, Miguel Angel Champin Catalan wrote: > We are students of computer sciences in the Santa Maria University, > Chile. We just want to know if the function "gets" it's too dangerous > for a warning. The fact is that our teacher's assistant give us a > homework, and one restriction was to use gcc to compile our code, > without warnings. As others said, it's not GCC directly giving you the warning. But nonetheless, it's good to understand where your logic is flawed. > We ask you for a simple explanation (if it's possible) about our > warning, telling that "gets" is not too dangerous, because in our case, > works perfectly, under some restrictions obviously. Simply reading the man page states: No check for buffer overrun is performed (see BUGS below). Hopefully, you know what a buffer overrun/overflow is and understand why it is therefore a very bad idea to be using gets even in academic work. Cheers! Jon.
Bootstrap broken
Somehow we still manage to break the bootstrap, even at the end of stage3: /files/pfeifer/OBJ-0902-2308/./gcc/xgcc -shared-libgcc -B/files/pfeifer/OBJ-0902-2308/./gcc -nostdinc++ -L/files/pfeifer/OBJ-0902-2308/i386-unknown-freebsd5.4/libstdc++-v3/src -L/files/pfeifer/OBJ-0902-2308/i386-unknown-freebsd5.4/libstdc++-v3/src/.libs -B/sw/gcc-current/i386-unknown-freebsd5.4/bin/ -B/sw/gcc-current/i386-unknown-freebsd5.4/lib/ -isystem /sw/gcc-current/i386-unknown-freebsd5.4/include -isystem /sw/gcc-current/i386-unknown-freebsd5.4/sys-include -I/files/pfeifer/OBJ-0902-2308/i386-unknown-freebsd5.4/libstdc++-v3/include/i386-unknown-freebsd5.4 -I/files/pfeifer/OBJ-0902-2308/i386-unknown-freebsd5.4/libstdc++-v3/include -I/sw/test/gcc/trunk/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c /sw/test/gcc/trunk/libstdc++-v3/src/mt_allocator.cc -fPIC -DPIC -o .libs/mt_allocator.o /sw/test/gcc/trunk/libstdc++-v3/src/mt_allocator.cc: In member function 'void __gnu_cxx::__pool::_M_reclaim_block(char*, size_t)': /sw/test/gcc/trunk/libstdc++-v3/src/mt_allocator.cc:278: error: expected unqualified-id before '=' token /sw/test/gcc/trunk/libstdc++-v3/src/mt_allocator.cc:292: error: expected primary-expression before '__attribute__' /sw/test/gcc/trunk/libstdc++-v3/src/mt_allocator.cc:292: error: expected `)' before '__attribute__' /sw/test/gcc/trunk/libstdc++-v3/src/mt_allocator.cc:293: error: expected primary-expression before '__attribute__' /sw/test/gcc/trunk/libstdc++-v3/src/mt_allocator.cc:293: error: expected `;' before '__attribute__' gmake[4]: *** [mt_allocator.lo] Error 1 gmake[4]: Leaving directory `/files/pfeifer/OBJ-0902-2308/i386-unknown-freebsd5.4/libstdc++-v3/src' gmake[3]: *** [all-recursive] Error 1 gmake[3]: Leaving directory `/files/pfeifer/OBJ-0902-2308/i386-unknown-freebsd5.4/libstdc++-v3' I don't see this on GNU/Linux, though, just FreeBSD 5.x. Timing (this started some 36 hours ago) and the position in the code indicate that this might be related to the following: 2006-09-02 Paolo Carlini <[EMAIL PROTECTED]> Richard Guenther <[EMAIL PROTECTED]> PR libstdc++/24469 * src/mt_allocator.cc (__pool::_M_reserve_block, __pool::_M_reclaim_block): Fix the logic to avoid races, exploit atomic counters stored in second part of the memory pointed by _M_used. (__pool::_M_initialize): Adjust _M_used allocation. * include/ext/mt_allocator.h (__pool::_Bin_record): Update comment. Gerald
Re: Bootstrap broken
On Mon, 2006-09-04 at 07:14 +0200, Gerald Pfeifer wrote: > Somehow we still manage to break the bootstrap, even at the end of stage3: Looks like __used is used by FreeBSD's headers (and not by glibc/Linux's headers). I forgot where the list of not to be used identifiers are so I cannot check if it is listed there or not. Thanks, Andrew Pinski
Re: Bootstrap broken
On Sun, 3 Sep 2006, Andrew Pinski wrote: > On Mon, 2006-09-04 at 07:14 +0200, Gerald Pfeifer wrote: >> Somehow we still manage to break the bootstrap, even at the end of stage3: > Looks like __used is used by FreeBSD's headers (and not by glibc/Linux's > headers). Bingo! Your nose is a good one, Sir. :-) /usr/include/sys/cdefs.h:#define __used __attribute__((__used__)) Gerald
Bug in Instruction Combination procedure and RTL generation.
Hi all,
I'm trying to debug a code optimization in gcc for an specific arch, to
be more explicit it's for gcc 2.95.3 for Metaware ARC target
architecture, i know the old release of compiler and i know there will
not be lot of support about it, anyway im keep on trying...,
In other words i noticed that when using -O0 flag the code generation is
correct but when using -Ox, where x=1,2,3 there's the following issue:
· Calling the compiler with the following debug flags:
-dr -dj -ds -dG -dL -df -dc -dN -dS -dl -dg -dR -dJ -dd
And inspecting the corresponding rtl files, i noticed a bad rtl
building/construction at following files and not for the others not
noted below:
.combine
.dbr
.greg
.jump2
.lreg
.regmove
.sched
.sched2
First, i don't know exactly the order of processing, i guess that
'.combine' comes after '.flow' one, and apparently '.flow' has correct
building, this is why i suspect that problem is in Instruction
Combination procedure.
The problem:
Using the following source code:
#define SINGULARP 10
#define SINGULARP_LOW 9
#define SINGULARP_HIGH 11
unsigned int
uifprb04503_A (unsigned int n)
{
unsigned int test_value = 69;
if ( n >= SINGULARP )
{
test_value = 20;
}
return test_value;
}
int main ()
{
if (uifprb04503_A (SINGULARP_LOW) != 69)
exit(1);
exit (0);
}
And using the -O2 flag, i get the following structure after objdump'ing
the object:
00ec :
ec: 00 36 0e 10 100e3600 st fp,[sp]
f0: 00 38 6e 63 636e3800 movfp,sp
f4: 08 7a e0 57 57e07a08 sub.f 0,r0,8
f8: 14 fe 1f 60 601ffe14 movr0,20
fc: 0e 7c 1f 60 601f7c0e mov.ls r0,69
100: 45 00 00 00
104: 20 80 0f 38 380f8020 j.d[blink]
108: 00 10 6e 0b 0b6e1000 ld.a fp,[sp]
010c :
10c: 04 3e 0e 10 100e3e04 st blink,[sp,4]
110: 00 36 0e 10 100e3600 st fp,[sp]
114: 00 38 6e 63 636e3800 movfp,sp
118: 10 7e 8e 53 538e7e10 subsp,sp,16
11c: a0 f9 ff 2f 29a0 bl.d ec
<...>
As you can see, the 3rd asm line at is not correctly
generated, it should be 'sub.f 0,r0,9'.
If you take a look to '.flow' file you can see the following 'good
strcture' for keeping the correct value on comparison:
--- (.flow)
(insn 4 37 5 (set (reg/v:SI 67)
(reg:SI 0 %r0)) 7 {*movsi_insn} (nil)
(expr_list:REG_DEAD (reg:SI 0 %r0)
(nil)))
<...>
(insn 12 11 32 (set (reg:CC 61 %cc)
(compare:CC (reg/v:SI 67)
(const_int 9 [0x9]))) 70 {*cmpsi_cc_insn} (insn_list 4
(nil))
(expr_list:REG_DEAD (reg/v:SI 67)
(nil)))
(insn 32 12 34 (set (reg:SI 71)
(const_int 20 [0x14])) 7 {*movsi_insn} (nil)
(expr_list:REG_EQUAL (const_int 20 [0x14])
(nil)))
(insn 34 32 14 (set (reg/v:SI 68)
(if_then_else (ltu (reg:CC 61 %cc)
(const_int 0 [0x0]))
(const_int 69 [0x45])
(reg:SI 71))) 29 {*movsicc_insn} (insn_list 12 (insn_list 32
(nil)))
(expr_list:REG_DEAD (reg:CC 61 %cc)
(expr_list:REG_DEAD (reg:SI 71)
(nil
<...>
But inspecting the '.combine' optimization, you'll get the '8' constant
value not expected:
(.combine)
(note 4 37 5 "" NOTE_INSN_DELETED)
<..>
(insn 12 11 32 (set (reg:CC 61 %cc)
(compare:CC (reg:SI 0 %r0)
(const_int 8 [0x8]))) 70 {*cmpsi_cc_insn} (nil)
(expr_list:REG_DEAD (reg:SI 0 %r0)
(nil)))
(insn 32 12 34 (set (reg:SI 71)
(const_int 20 [0x14])) 7 {*movsi_insn} (nil)
(expr_list:REG_EQUAL (const_int 20 [0x14])
(nil)))
(insn 34 32 14 (set (reg/v:SI 68)
(if_then_else (leu (reg:CC 61 %cc)
(const_int 0 [0x0]))
(const_int 69 [0x45])
(reg:SI 71))) 29 {*movsicc_insn} (insn_list 12 (insn_list 32
(nil)))
(expr_list:REG_DEAD (reg:CC 61 %cc)
(expr_list:REG_DEAD (reg:SI 71)
(nil
<...>
---
Not an expert on RTL generation/optimization but i imagine that problem
could be on gcc internals than in arc.md rules definition, anyway not
sure about it, feel free to ask for affected rules in .md file.
By the way, you have a workaround to all of this situation. If you place
another 'source line' in statement block at 'if' testing, you get the
properly results, iow:
uifprb04503_A (unsigned int n)
{
unsigned int test_value = 69;
unsigned int dummy_value = 69;
if ( n >= SINGULARP )
{
test_value = 20;
dummy_value = test_value + 4; /* added 2 avoid bad object */
}
<...>
Hint's and Help appreciated
Have a good day
Jose.
