Re: GCC 4.4.0 Status Report (2009-03-13)

On Sun, Mar 22, 2009 at 02:00:53PM -0700, Steven Bosscher wrote: > Perhaps it was true more 12 years ago than today. The whole idea of > FOSS is probably better understood than 12 years ago. At least, > projects like Linux and LLVM attract contributions from large > companies without involvement

Re: GCC 4.4.0 Status Report (2009-03-13)

On Sun, Mar 22, 2009 at 11:53:59PM -0700, NightStrike wrote: > On Mon, Mar 23, 2009 at 2:32 AM, Joe Buck wrote: > > one. RMS wanted to have gcc use machines administered by the FSF; we > > pushed back. gcc.gnu.org is sourceware.org. We did agree that we > > A little off-topic, but why *is* gcc

Re: GCC 4.4.0 Status Report (2009-03-13)

On Mon, Mar 23, 2009 at 2:38 AM, Joe Buck wrote: > > GCC uses are the ones developed in the egcs days. Remember the old > > days when the location of the development tree and the snapshots was > > a secret, and people were threatened with banning if they let it out? On Sun, Mar 22, 2009 at 11:5

Re: GCC 4.4.0 Status Report (2009-03-13)

On Mon, 2009-03-23 at 11:54 +1100, Ben Elliston wrote: > Can you give some indication of how the subset is enforced? I find it weird that you choose to ignore the obvious: code reviews, maintainer management, etc. Just like what you (gcc developers) do in gcc's C codebase everyday. Unless, of co

Re: GCC 4.4.0 Status Report (2009-03-13)

NightStrike wrote: On Mon, Mar 23, 2009 at 2:38 AM, Joe Buck wrote: GCC uses are the ones developed in the egcs days. Remember the old days when the location of the development tree and the snapshots was a secret, and people were threatened with banning if they let it out? Are you se

Re: GCC 4.4.0 Status Report (2009-03-13)

> > GCC uses are the ones developed in the egcs days. Remember the old > > days when the location of the development tree and the snapshots was > > a secret, and people were threatened with banning if they let it out? > > Are you serious? Why would it be handled that way? It's hard to remember b

Re: GCC 4.4.0 Status Report (2009-03-13)

On Mon, Mar 23, 2009 at 6:24 AM, Joel Sherrill wrote: > NightStrike wrote: >> >> On Mon, Mar 23, 2009 at 2:38 AM, Joe Buck wrote: >> >>> >>> GCC uses are the ones developed in the egcs days.  Remember the old >>> days when the location of the development tree and the snapshots was >>> a secret, a

Re: -fdump-translation-unit does'nt dump as expected.

I was earlier using Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --wit

Re: -fdump-translation-unit does'nt dump as expected.

On Mon, Mar 23, 2009 at 10:17, Praveen D V wrote: > With the new version I'm not able to get those dumps. > I just downloaded latest release and compiled it.  It too doesn't dump > those typedef trees. > Any other pointers? You will need to modify the GCC dump routines yourself to dump the typed

any recent changes to gcc test builds

Hi, I am confused at the gcc test results for RTEMS over the weekend. I have 1000s of failures across all the targets which look like this: Executing on host: /home/joel/test-gcc/b-gcc1-sparc/gcc/xgcc -B/home/joel/test-gcc/b-gcc1-sparc/gcc/ /home/joel/test-gcc/gcc-svn/gcc/testsuite/gcc.c-tort

Re: any recent changes to gcc test builds

> Date: Mon, 23 Mar 2009 09:37:02 -0500 > From: Joel Sherrill > I am confused at the gcc test results for RTEMS > over the weekend. I have 1000s of failures > across all the targets which look like this: > Any ideas? I fixed a bug in Janis' GCC_EXEC_PREFIX testsuite cleanup:

Re: any recent changes to gcc test builds

Hans-Peter Nilsson wrote: Date: Mon, 23 Mar 2009 09:37:02 -0500 From: Joel Sherrill I am confused at the gcc test results for RTEMS over the weekend. I have 1000s of failures across all the targets which look like this: Any ideas? I fixed a bug in Janis' GCC_EXEC_PR

Re: any recent changes to gcc test builds

> Date: Mon, 23 Mar 2009 10:19:37 -0500 > From: Joel Sherrill > I don't have those in my board.exp: > > set_board_info cflags "-B${RTEMS_MAKEFILE_PATH}/lib/ -specs bsp_specs > -qrtems -mcpu=603e" > set_board_info ldflags "${RTEMS_CONFIG_OBJ}" Those should find ${RTEMS_MAKEFILE_PATH}/lib/libm.

Re: query automaton

Alex Turjan wrote: Vladimir thanks for help! With respect to your answer I would like to point to you a possible way to solve the scheduling problem (which I think wont be too difficult to be implemented in genautomata). Alex, thanks for sharing your thoughts. I also thought about this a

Re: Interpreting stack frame

On Fri, Mar 20, 2009 at 4:54 PM, Ian Lance Taylor wrote: > Peter Leist writes: > >> How can I interpret the stack frame of the current_function? That >> means, how can >> I tell what is stored at the location FP+xxx. If that is not (easily) >> possible, it would >> help if I can somehow determine

Re: Interpreting stack frame

Peter Leist wrote: > On Fri, Mar 20, 2009 at 4:54 PM, Ian Lance Taylor wrote: >> Peter Leist writes: >> >>> How can I interpret the stack frame of the current_function? That >>> means, how can >>> I tell what is stored at the location FP+xxx. If that is not (easily) >>> possible, it would >>> hel

Problem with a cross-compiler based on gcc-trunk

Hi, I am testing a cross-compiler targetting arm-wince-pe and based on gcc-trunk revision r144975 and when compiling a project I get the following error : vinc...@vincent-pc:~/projects$ arm-mingw32ce-gcc -std=gnu99 -save-temps -I/home/vincent/local/wince/include -DNDEBUG -O3 -c cegcc-errno-bug.c

Re: Interpreting stack frame

On Mon, Mar 23, 2009 at 5:52 PM, Andrew Haley wrote: > Peter Leist wrote: >> >> I understand that, but at a given point in the program flow the assignment >> of stack slot to a variable should be fixed. > > Should it?  We do some very drastic transformations in gcc, sometimes > coalescing variable

Re: Deprecating Itanium1 for GCC 4.4

On Fri, 2009-03-20 at 00:24 +0100, Steven Bosscher wrote: > On Sun, Mar 15, 2009 at 9:39 PM, Gerald Pfeifer wrote: > >> I can't find any test results in gcc-testresults reported with > >> -mtune=itanium1 [1]. > > > > ...especially if theye do not even contribute test results or > > feedback when t

Re: Problem with a cross-compiler based on gcc-trunk

Vincent R. wrote: > vinc...@vincent-pc:~/projects$ arm-mingw32ce-gcc -std=gnu99 -save-temps > -I/home/vincent/local/wince/include -DNDEBUG -O3 -c cegcc-errno-bug.c > -DDLL_EXPORT -DPIC -o libeet_la-eet_lib.o > cegcc-errno-bug.c: In function 'eet_close': > cegcc-errno-bug.c:134: error: unrecogniza

Re: any recent changes to gcc test builds

Hans-Peter Nilsson wrote: Date: Mon, 23 Mar 2009 10:19:37 -0500 From: Joel Sherrill I don't have those in my board.exp: set_board_info cflags "-B${RTEMS_MAKEFILE_PATH}/lib/ -specs bsp_specs -qrtems -mcpu=603e" set_board_info ldflags "${RTEMS_CONFIG_OBJ}" Those should find $

Re: Problem with a cross-compiler based on gcc-trunk

On Mon, 23 Mar 2009 18:51:50 +, Dave Korn wrote: > Vincent R. wrote: > >> vinc...@vincent-pc:~/projects$ arm-mingw32ce-gcc -std=gnu99 -save-temps >> -I/home/vincent/local/wince/include -DNDEBUG -O3 -c cegcc-errno-bug.c >> -DDLL_EXPORT -DPIC -o libeet_la-eet_lib.o >> cegcc-errno-bug.c: In fun

Variable length arrays : aligned on stack

Dear all, I've been looking to a problem where if I have this defined in the function: void foo(int len) { long arr[len]; ... } I get a complicated code to calculate the address of this variable-length array. It seems that the compiler is aligning the array when this code: void foo(int len) { l

Re: GCC 4.4.0 Status Report (2009-03-13)

> "Joe" == Joe Buck writes: Joe> I do think that RMS overstepped the line that we had set up when he Joe> told us to hold off on creating a release branch. That was unprecedented Joe> interference. Then why acquiesce to it? I've seen other statements on this thread indicating that the SC w

Re: GCC 4.4.0 Status Report (2009-03-13)

> "Dan" == Daniel Berlin writes: Dan> Also, do you not realize this is precisely because of the massive lack Dan> of transparency about how the project is governed? A bit more transparency would be nice. Recently I've been thinking: let's have a periodic election for a developer ombudsman m

Re: Typo or intended?

Bingfeng Mei wrote: Hello, I just updated our porting to include last 2-3 weeks of GCC developments. I noticed a large number of test failures at -O1 that use a user-defined data type (based on a special register file of our processor). All variables of such type are now spilled to memory whic

Re: GCC 4.4.0 Status Report (2009-03-13)

On Mon, Mar 23, 2009 at 12:32:17PM -0700, Tom Tromey wrote: > > "Joe" == Joe Buck writes: > > Joe> I do think that RMS overstepped the line that we had set up when he > Joe> told us to hold off on creating a release branch. That was unprecedented > Joe> interference. > > Then why acquiesce

Re: GCC 4.4.0 Status Report (2009-03-13)

Richard Guenther writes: >> But anyway, is the official position of the FSF still "thou shall use >> not C++"? That would mean GNU binutils is in violation with gold, no? > > Probably people were clever enough not to ask the FSF about this ;) Correct: I certainly did not ask the FSF about gold,

Re: GCC 4.4.0 Status Report (2009-03-13)

NightStrike writes: > On Mon, Mar 23, 2009 at 2:38 AM, Joe Buck wrote: >> GCC uses are the ones developed in the egcs days.  Remember the old >> days when the location of the development tree and the snapshots was >> a secret, and people were threatened with banning if they let it out? > > Are y

Re: GCC 4.4.0 Status Report (2009-03-13)

Joe Buck writes: > On Sun, Mar 22, 2009 at 11:53:59PM -0700, NightStrike wrote: >> On Mon, Mar 23, 2009 at 2:32 AM, Joe Buck wrote: >> > one. RMS wanted to have gcc use machines administered by the FSF; we >> > pushed back. gcc.gnu.org is sourceware.org. We did agree that we >> >> A little o

Re: GCC 4.4.0 Status Report (2009-03-13)

domi...@lps.ens.fr (Dominique Dhumieres) writes: > Could someone at FSF, directly or through the SC, be kind enough to > explain in plain English for non-native speakers why it was so urgent > to disrupt the release process for a licence exception. I don't think any of us know. You would have to

Re: Posix C++ integration

On 3/21/09, Aayush saxena wrote: > I am interested in Posix C++ integration. Does this suggested > idea incorporates the integration of standard C interface of > Posix thread library by encapsulating C structure into the C++ > class? Some Posix and C-language functions are non-reentrant with > res

Re: GCC 4.4.0 Status Report (2009-03-13)

On Mon, Mar 23, 2009 at 01:04:15PM -0700, Ian Lance Taylor wrote: > By the way, from reading this messages I think that people have a > slightly rosier recollection of the egcs split than I do. I think the > egcs split was the right thing to do, but it was also a power play on > the part of Cygnus

Re: GCC C FRONT END EXPLANATION

hey, could you guys explain me something? in c-parser.c in c_parser_direct_declarator, when a function name is being parsed, this if: if (c_parser_next_token_is (parser, CPP_OPEN_PAREN)) is true, and inside this if: c_parser_consume_token (parser); attrs = c_parser_attributes (parse

Re: GCC C FRONT END EXPLANATION

Eduardo Cruz writes: > but in c_parser_attributes this is made in the beggining of the loop: ... > and why does it require the token "(" ? aren't we inside the function > parameters list? No. At that point the parser is reading the function attributes. The comments explain the syntax in deta

Re: GCC 4.4.0 Status Report (2009-03-13)

Chris Lattner wrote: These companies really don't care about FOSS in the same way GCC developers do. I'd be highly confident that this would still be a serious issue for the majority of the companies I've interacted with through the years. Hi Jeff, Can you please explain the differences

Re: GCC 4.4.0 Status Report (2009-03-13)

Jeff Law wrote: > The first camp sees FOSS toolkits as a means to help them sell more > widgets, typically processors & embedded development kits. Their belief > is that a FOSS toolkit helps build a developer eco-system around their > widget, which in turn spurs development of consumable devices

Re: GCC 4.4.0 Status Report (2009-03-13)

Dave Korn wrote: Jeff Law wrote: The first camp sees FOSS toolkits as a means to help them sell more widgets, typically processors & embedded development kits. Their belief is that a FOSS toolkit helps build a developer eco-system around their widget, which in turn spurs development of cons