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

[Joe Buck]

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 of the FSF.

Linux has the Linux Foundation signing Linus's paycheck.  Many other
large free software projects have some kind of foundation; others
are the captive of one company (e.g. OpenOffice.org).

If Linus were to accept employment from Red Hat or Novell, there would
be a massive stink and we'd see the old Unix wars (OSF vs AT&T/Sun,
etc) all over again.  Thinks haven't changed that much; having a
neutral body helps a lot.

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

[Joe Buck]

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 on sourceware.org?

Because long ago, Cygnus (now part of Red Hat) contributed hosting for the
egcs project, and it happens to be the same machine.  The egcs project
had a very nice setup, and when egcs became GCC it was kept.

But gcc.gnu.org is a different virtual host (for http purposes) than
sourceware.org, so you only notice it's the same machine if you use
ftp or check the IP address.

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

[Joe Buck]

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:52:25PM -0700, NightStrike wrote:
> Are you serious?  Why would it be handled that way?

Yes, I'm serious; it was a hidden directory on vger.rutgers.edu, and the
README file in the directory contained the banning threat, though as far
as I know the threat was never actually carried out.

As for why, I don't know.  Maybe Kenner has some idea.

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

[Mathieu Lacage]

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 course, gcc grew an automatic code
checker overnight for ugly code ?

regards,
Mathieu

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

[Joel Sherrill]

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 serious?  Why would it be handled that way?
  

I don't know either but this was another part of the egcs
move to the bazaar that seems obvious in retrospect.

Given what gcc is now, it is hard to believe that the
gcc testsuites, Standard C++ libraries and the
other language support that existed at that time was
all in separately maintained and distributed pieces.
You were individually responsible for assembling the
pieces if you wanted a C++ compiler.  Hard to believe
but that's the way it was.

Which also points out another reason egcs happened.
There was a HUGE backlog of work that needed to
be merged into one gcc package.  egcs broke that
logjam and gcc improved rapidly.

I just hope there is news from the FSF this morning so
we can get back to work. :)

--joel

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

[Richard Kenner]

> > 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 back to those days, but basically it was because
of concerns people wouldn't appreciate the fact that the development
versions were just that and known to be buggy, would use them anyway,
and badmouth GCC.  Now it's quite common to have these sorts of "unstable"
versions of Free Software out there, so people are aware of this, but back
then this was more "uncharted territory".

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

[Gabriel Dos Reis]

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, and people were threatened with banning if they let it out?
>>>
>>
>> Are you serious?  Why would it be handled that way?
>>
>
> I don't know either but this was another part of the egcs
> move to the bazaar that seems obvious in retrospect.
>
> Given what gcc is now, it is hard to believe that the
> gcc testsuites, Standard C++ libraries and the
> other language support that existed at that time was
> all in separately maintained and distributed pieces.
> You were individually responsible for assembling the
> pieces if you wanted a C++ compiler.  Hard to believe
> but that's the way it was.

yes, that was a nightmare.

-- Gaby

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

[Praveen D V]

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
--with-gxx-include-dir=/usr/include/c++/4.1.3 --program-suffix=-4.1
--enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug
--enable-mpfr --enable-checking=release x86_64-linux-gnu
Thread model: posix
gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)

This dumps every typedef.

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?

--regards, Praveen

On Sat, Mar 21, 2009 at 12:42 AM, Diego Novillo  wrote:
> On Thu, Mar 5, 2009 at 11:25, Praveen D V  wrote:
>
>> $gcc -fdump-translation-unit try.c
>>  generates try.c.001t.tu (earlier versions generated try.c.tu). I
>> don't see any reference of MyStruct in the generated file.
>> Please help, am I missing any thing in the process?
>
> The dumps are meant to be used when debugging the compiler.  They are
> not meant to be complete.  In particular global type definitions are
> never dumped.
>
>
> Diego.
>

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

[Diego Novillo]

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
typedefs.  Start with dump_node and the calls made to dump_begin
(TDI_tu,...).

As I said before, these routines change almost constantly and we don't
even try to keep the output consistent.  They are just debug
instruments for us.


Diego.

any recent changes to gcc test builds

[Joel Sherrill]

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-torture/execute/930930-1.c  
-w  -O3 -fomit-frame-pointer -funroll-loops  -DSTACK_SIZE=2048 
-B/home/joel/test-gcc/bsp-install/sparc-rtems4.10/sis/lib/ -specs 
bsp_specs -qrtems -mcpu=cypress 
/home/joel/test-gcc/b-gcc1-sparc/rtems_gcc_main.o  -lm   -o 
/home/joel/test-gcc/b-gcc1-sparc/gcc/testsuite/gcc/930930-1.x4
(timeout = 300)

/home/joel/test-gcc/install/sparc-rtems4.10/bin/ld: cannot find -lm
collect2: ld returned 1 exit status

I haven't changed the configure command in the test script
and there are lots of libm.a's in the tree.  The command
just doesn't seem to be picking up the directory with libm.a.

Any ideas?

b-gcc1-sparc/sparc-rtems4.10/v8/newlib/libm.a
b-gcc1-sparc/sparc-rtems4.10/v8/newlib/libm/libm.a
b-gcc1-sparc/sparc-rtems4.10/newlib/libm.a
b-gcc1-sparc/sparc-rtems4.10/newlib/libm/libm.a
b-gcc1-sparc/sparc-rtems4.10/soft/v8/newlib/libm.a
b-gcc1-sparc/sparc-rtems4.10/soft/v8/newlib/libm/libm.a
b-gcc1-sparc/sparc-rtems4.10/soft/newlib/libm.a
b-gcc1-sparc/sparc-rtems4.10/soft/newlib/libm/libm.a

--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: any recent changes to gcc test builds

[Hans-Peter Nilsson]

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

Not that I see why this'd have any bearing on your failures;
-B's should be translated to -L's and the (presumably present)
 set_board_info ldflags   "[libgloss_link_flags] [newlib_link_flags]"
in your .exp should help finding the newlib libraries.
(Hm, maybe I presumed too much and you don't have that!)

brgds, H-P

Re: any recent changes to gcc test builds

[Joel Sherrill]

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_PREFIX testsuite cleanup:
.

Not that I see why this'd have any bearing on your failures;
-B's should be translated to -L's and the (presumably present)
 set_board_info ldflags   "[libgloss_link_flags] [newlib_link_flags]"
in your .exp should help finding the newlib libraries.
(Hm, maybe I presumed too much and you don't have that!)

  

No.  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}"

Where do I need to add those?  Can you point me
to examples?

I have attached the complete rtems-powerpc-psim.exp
in case that helps.  It isn't very large.

Thanks.



brgds, H-P
  



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985


# Copyright (C) 1997-2008 Free Software
# Foundation, Inc.
#
# This file is part of DejaGnu.
#
# DejaGnu is free software; you can redistribute it and/or modify it
# under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# DejaGnu is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with DejaGnu; if not, write to the Free Software Foundation,
# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

# This is a list of toolchains that are supported on this board.
set_board_info target_install {powerpc-rtems4.9}

# Load the generic configuration for this board, This will define a basic
# set of routines needed by the tool to communicate with the board.
load_generic_config "sim"

# basic-sim.exp is a basic description for the standard Cygnus simulator.
load_base_board_description "basic-sim"

# The name of the simulator is "ppc".
setup_sim psim

# No multilib flags needed by default.
process_multilib_options ""

# The compiler used to build for this board. This has *nothing* to do
# with what compiler is tested if we're testing gcc.
set_board_info compiler  "[find_gcc]"

set_board_info cflags  "-B${RTEMS_MAKEFILE_PATH}/lib/ -specs bsp_specs -qrtems 
-mcpu=603e"
set_board_info ldflags "${RTEMS_CONFIG_OBJ}"

# The simulator isn't really remote.
set_board_info isremote 0

# We only have a small stack available to us
set_board_info gcc,stack_size 2048

# wrapper script which handles the device tree
set_board_info sim "psim -l 180"

# No support for signals on this target.
set_board_info gdb,nosignals 1

# The simulator doesn't return exit statuses and we need to indicate this.
set_board_info needs_status_wrapper 1

# Can't call functions from GDB.
# set_board_info gdb,cannot_call_functions 1

Re: any recent changes to gcc test builds

[Hans-Peter Nilsson]

> 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.a which might
or might not be what you want.

> Where do I need to add those?  Can you point me
> to examples?

I'd grep among the other baseboards for numerous examples, in
the dejagnu installation, subdir baseboards.  In case you have
no clue where it is on the system where you test, you'll see it
as:
...
Using /config/sim.exp as generic interface file for 
target.
...

when running the test-suite.

brgds, H-P

Re: query automaton

[Vladimir Makarov]

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 few 
years ago when I tried to implement automatic splitting of original 
automaton.  In this case we could rid off define_automata construction 
but I see that it would be a sacrifice in debugging automaton as your 
proposal (because automatic generation of automata and fake instructions 
in .dfa file could be confusing for people).  On the other 
hand people might be confused about rules to assign units to automata.


I would not say your proposal will be easy to implement.  I'd evaluate 
it as 2-3 weeks of additional work to a patch I am working on.   I 
recently practically finished this patch checking the correctness of 
assigning functional units to automata.  This code could be used to 
implement your proposal (to check when we need insn_reservation 
splitting).  I found only three incorrect target automata:


m68k (coldfire)
power4
power5

The first description can be easily corrected by removing one 
automaton.  The last two required more changes because removing automata 
does not permit to create reasonable size automata.  Power5 description 
changes did not result in different code generation (at least on 
SPEC2000).  Power4 changes result in different code generation but 
practically the same SPEC scores.


So I'll stop on this patch for now and put your proposal on my TODO list 
because it has some merits.


Splitting automaton is a complicated issue and it needs some research.  
Rubin (see reference to articles in genautomata.c) did this but only  
for automaton generated from regexps without alternatives.  GCC is the 
first compiler which permits alternatives (and even their 
non-deterministic treatment).  I also thought about more advanced models 
than DFA and NDFA to describe more sophisticated pipeline hazards (as 
hidden registers for renaming or different insn queues  constraints in 
OOO processors) but I think the current model already achieved a good 
balance of complexity description and its outcome for insn scheduler.  
All these areas are good for research if somebody wants to do a research.


To explain it, I will make use of the “move insn” example pointed in the previous email. 
First of all I do not change anything in the 2 automatons (aut1 and aut2); they are correctly built by the genautomata. 
Next to the original 
  
(define_reservation "move"  "(  (unit1_aut1, unit1_aut2) |  
   (unit2_aut1, unit2_aut2)  ) 



I define two separate fake move instructions (i.e., “move_fake1” and 
“move_fake2”) of which semantic does play any role; each of them
having a unit reservation one of the alternatives of the “move”:

(define_reservation "move_fake1"  "( (unit1_aut1, unit1_aut2)), and 
(define_reservation "move_fake2"  "( (unit2_aut1, unit2_aut2) ).


Those two extra moves are then used during the sched2 target hook 
TARGET_SCHED_DFA_NEW_CYCLE to decide which of the move alternative unit 
reservations can be correctly claimed.
Suppose the ready instruction is a “move”.
First I make 2 copies of the current state: temp_state1 and temp_state2.
Then I check which of the two fake moves ( “move_fake1” and “move_fake2”) with 
different unit occupation can be issued at the current state:
cost_move_fake1 = internal_state_transition (insn_code_move_fake1, temp_state1);
cost_move_fake2 = internal_state_transition (insn_code_move_fake2, temp_state2);

Once I find the correct choice (suppose cost_move_fake1 <0),  I set 
dfa_insn_codes[] of the ready instruction to the one of  move_fake1.

  int uid = INSN_UID (ready);
 if (uid >= dfa_insn_codes_length)
dfa_insn_code_enlarge (uid);   
dfa_insn_codes[uid] = internal_dfa_insn_code (insn_code_move_fake1);


In this way when the scheduler calls internal_state_transition, the ready 
instruction has been already set its dfa_insn_codes to a unit reservation 
schedulable in the current state.
  

Re: Interpreting stack frame

[Peter Leist]

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 the type of data stored at that
>> location (i.g is that
>> a reference to a variable or the contents of a variable).
>
> Stack slots can be shared by different variables, so I'm not sure there
> is a coherent answer to this.

I understand that, but at a given point in the program flow the assignment
of stack slot to a variable should be fixed.

> That said, look at assign_stack_local and
> assign_stack_temp in gcc/function.c.

Thanks for the pointer, but it seams these functions are responsible only
for arguments, not for local variables (at least assign_stack_local).

What I try to achieve is: Given the frame pointer for a function X, how can I
tell which of the used stack frames hold what data (at a given time in
the program flow).
To be more exact, I would like to know that before a call is taken. I want to
tell for every stack slot of the *calling* function if the data in that slot is
passed to the called function as a reference or not

Every debugger should be able to tell that, or am I wrong? Can I probably
extract the information from debug data? I've seen a reference to
x_stack_slot_list
in assign_stack_local.c but that doesn't seem to do the trick.

Thanks,
Peter

Re: Interpreting stack frame

[Andrew Haley]

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
>>> help if I can somehow determine the type of data stored at that
>>> location (i.g is that
>>> a reference to a variable or the contents of a variable).
>> Stack slots can be shared by different variables, so I'm not sure there
>> is a coherent answer to this.
> 
> 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 variables, sometimes eliminating them altogether, and
sometimes creating new ones which have no equivalent in the source.
This is all business as usual for an optimizing compiler.

> What I try to achieve is: Given the frame pointer for a function X, how can I
> tell which of the used stack frames hold what data (at a given time in
> the program flow).
> To be more exact, I would like to know that before a call is taken. I want to
> tell for every stack slot of the *calling* function if the data in that slot 
> is
> passed to the called function as a reference or not
> 
> Every debugger should be able to tell that, or am I wrong? Can I probably
> extract the information from debug data?

Yes, but as I explain above the information is not going to be complete.

Andrew.

Problem with a cross-compiler based on gcc-trunk

[Vincent R.]

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 
-DDLL_EXPORT -DPIC -o libeet_la-eet_lib.o
cegcc-errno-bug.c: In function 'eet_close':
cegcc-errno-bug.c:134: error: unrecognizable insn:
(insn 6 5 7 3 cegcc-errno-bug.c:114 (set (reg/f:SI 138)
(symbol_ref:SI ("errno") [flags 0x4c0] )) -1 (nil))
cegcc-errno-bug.c:134: internal compiler error: in extract_insn, at
recog.c:2048

Of course I could report a bug but since original sources are patched the
bug might be due to one 
of the modifications.
Anyway if someone knows how I could fix this, the only thing I see is the
fact the problem seems to be
related to errno and on wince platform by default there is no errno.
So the project I am compiling declare it like this and is defined in a
library.

/home/vincent/local/wince/include/errno.h:

#ifndef __EVIL_ERRNO_H__
#define __EVIL_ERRNO_H__

#ifdef EAPI
# undef EAPI
#endif /* EAPI */

#ifdef _WIN32
# ifdef EFL_EVIL_BUILD
#  ifdef DLL_EXPORT
#   define EAPI __declspec(dllexport)
#  else
#   define EAPI
#  endif /* ! DLL_EXPORT */
# else
#  define EAPI __declspec(dllimport)
# endif /* ! EFL_EVIL_BUILD */
#endif /* _WIN32 */

#ifdef  __cplusplus
extern "C" {
#endif

extern EAPI int errno;

/* Fake values */
#define E2BIG   1
#define EACCES  2
...

#ifdef  __cplusplus
}
#endif

#endif /* __EVIL_ERRNO_H__ */
-
And here is the testcase :

//#ifdef HAVE_CONFIG_H
//# include 
//#endif

#ifdef HAVE_ALLOCA_H
# include 
#elif defined __GNUC__
# define alloca __builtin_alloca
#elif defined _AIX
# define alloca __alloca
#elif defined _MSC_VER
# include 
# define alloca _alloca
#else
# include 
# ifdef  __cplusplus
extern "C"
# endif
void *alloca (size_t);
#endif

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifdef HAVE_OPENSSL
#include 
#endif

#ifdef HAVE_NETINET_IN_H
# include 
#endif

#if defined(_WIN32) && ! defined(__CEGCC__)
# include 
#endif

//#ifdef HAVE_EVIL
//# include 
//#endif

#ifdef HAVE_GNUTLS
# include 
# include 
#endif

#ifdef HAVE_OPENSSL
# include 
# include 
#endif

//#include 

//#include "Eet.h"
//#include "Eet_private.h"

#ifdef HAVE_REALPATH
#undef HAVE_REALPATH
#endif

#define EET_MAGIC_FILE  0x1ee7ff00
#define EET_MAGIC_FILE_HEADER   0x1ee7ff01

#define EET_MAGIC_FILE2 0x1ee70f42

 typedef enum _Eet_File_Mode
 {
EET_FILE_MODE_INVALID = -1,
EET_FILE_MODE_READ,
EET_FILE_MODE_WRITE,
EET_FILE_MODE_READ_WRITE
 } Eet_File_Mode;

   typedef enum _Eet_Error
 {
EET_ERROR_NONE,
EET_ERROR_BAD_OBJECT,
EET_ERROR_EMPTY,
EET_ERROR_NOT_WRITABLE,
EET_ERROR_OUT_OF_MEMORY,
EET_ERROR_WRITE_ERROR,
EET_ERROR_WRITE_ERROR_FILE_TOO_BIG,
EET_ERROR_WRITE_ERROR_IO_ERROR,
EET_ERROR_WRITE_ERROR_OUT_OF_SPACE,
EET_ERROR_WRITE_ERROR_FILE_CLOSED,
EET_ERROR_MMAP_FAILED,
EET_ERROR_X509_ENCODING_FAILED,
EET_ERROR_SIGNATURE_FAILED,
EET_ERROR_INVALID_SIGNATURE,
EET_ERROR_NOT_SIGNED,
EET_ERROR_NOT_IMPLEMENTED,
EET_ERROR_PRNG_NOT_SEEDED,
EET_ERROR_ENCRYPT_FAILED,
EET_ERROR_DECRYPT_FAILED
 } Eet_Error;

/* prototypes of internal calls */
static Eet_Erroreet_flush2(int *ef);

/* flush out writes to a v2 eet file */
static Eet_Error
eet_flush2(int *ef)
{
Eet_Error error = EET_ERROR_NONE;
 
switch (errno)
  {
   case EFBIG: error = EET_ERROR_WRITE_ERROR_FILE_TOO_BIG; break;
   case EIO: error = EET_ERROR_WRITE_ERROR_IO_ERROR; break;
   case ENOSPC: error = EET_ERROR_WRITE_ERROR_OUT_OF_SPACE; break;
   case EPIPE: error = EET_ERROR_WRITE_ERROR_FILE_CLOSED; break;
   default: error = EET_ERROR_WRITE_ERROR; break;
  }

   return error;
}

EAPI Eet_Error
eet_close(int *ef)
{
   Eet_Error err;

   err = eet_flush2(ef);
  
   return err;
} // L134 : where gcc crash


If I comment the errno variable inside the switch and replace it by 1 for
instance, it compiles fine.
Where should I start ?

Re: Interpreting stack frame

[Peter Leist]

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 variables, sometimes eliminating them altogether, and
> sometimes creating new ones which have no equivalent in the source.
> This is all business as usual for an optimizing compiler.

Ok, I think I expressed my goals unclear. I do not want to link a slot 1:1
to a source-code variable. It is clear that such a relation does not exist
in an optimized code.

Maybe I have to ask the other way around: How can I find out
which stack slots of the current function may get changed be a called
function. Or in other words: At each call of an other function, I want to
know which stack slots (not variables) are passed as arguments via reference.

>> Every debugger should be able to tell that, or am I wrong? Can I probably
>> extract the information from debug data?
>
> Yes, but as I explain above the information is not going to be complete.

As stated above, I probably don't need complete information.

Peter

Re: Deprecating Itanium1 for GCC 4.4

[Steve Ellcey]

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 things are broken (as in this case).  Deprecating
> > Itanium 1 with GCC 4.4 sounds very reasonable.
> 
> Very well. Like so?
> I'll propose something for gcc-4.4/changes.html too, after this is
> approved in some form.
> 
> Ciao!
> Steven

Sorry for not chiming in sooner but I have been on Vacation.  I think
depreciating Itanium1 tuning for 4.4 and removing it in 4.5 is
reasonable.  Code generated and tuned for Itanium2 should run fine on
Itanium1 (Merced).  It won't be scheduled optimally of course, but it
should run correctly.

> 
> 
> 
>   * config/ia64/ia64.c (ia64_handle_option): Inform user that Itanium1
>   support is deprecated if the -mtune value is set to an Itanium1
>   variant.
> 
> Index: config/ia64/ia64.c
> ===
> --- config/ia64/ia64.c(revision 144970)
> +++ config/ia64/ia64.c(working copy)
> @@ -5212,6 +5212,8 @@ fix_range (const char *const_str)
>  static bool
>  ia64_handle_option (size_t code, const char *arg, int value)
>  {
> +  static bool warned_merced_deprecated = false;
> +
>switch (code)
>  {
>  case OPT_mfixed_range_:
> @@ -5245,6 +5247,13 @@ ia64_handle_option (size_t code, const char *arg,
> if (!strcmp (arg, processor_alias_table[i].name))
>   {
> ia64_tune = processor_alias_table[i].processor;
> +   if (ia64_tune == PROCESSOR_ITANIUM
> +   && ! warned_merced_deprecated)
> + {
> +   inform ("value %<%s%> for -mtune= switch is deprecated", arg);
> +   inform ("GCC 4.4 is the last release with Itanium1 support");
> +   warned_merced_deprecated = true;
> + }
> break;
>   }
>   if (i == pta_size)

I will approve this patch, but it should say "Itanium1 tuning support"
or something like that.  The code will run on Itanium1, just not
optimally.

Steve Ellcey
s...@cup.hp.com

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

[Dave Korn]

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: unrecognizable insn:
> (insn 6 5 7 3 cegcc-errno-bug.c:114 (set (reg/f:SI 138)
> (symbol_ref:SI ("errno") [flags 0x4c0]  errno>)) -1 (nil))
> cegcc-errno-bug.c:134: internal compiler error: in extract_insn, at
> recog.c:2048

> Of course I could report a bug but since original sources are patched the
> bug might be due to one of the modifications.
> And here is the testcase :

  You could probably have cut that down just to the definition of errno,
Eet_Error and eet_flush2.  Which actual definition of EAPI were you using?

> If I comment the errno variable inside the switch and replace it by 1 for
> instance, it compiles fine.
> Where should I start ?

  First thing would be to try and figure out why the insn isn't being
recognized.  This is rather odd unless your patch has affected the movsi
definition in the .md file.  Does the error go away if you make sure there is
no dllimport/export attribute?

cheers,
  DaveK

Re: any recent changes to gcc test builds

[Joel Sherrill]

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 ${RTEMS_MAKEFILE_PATH}/lib/libm.a which might
or might not be what you want.
  

Not. :)  That only points to RTEMS libraries for a particular
board.
  

Where do I need to add those?  Can you point me
to examples?



I'd grep among the other baseboards for numerous examples, in
the dejagnu installation, subdir baseboards.  In case you have
no clue where it is on the system where you test, you'll see it
as:
...
Using /config/sim.exp as generic interface file for 
target.
...

when running the test-suite.
  

Fixed and closed the single PR I was testing when I
ran into this.

Thanks.

brgds, H-P
  



--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherr...@oarcorp.comOn-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

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

[Vincent R.]

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 function 'eet_close':
>> cegcc-errno-bug.c:134: error: unrecognizable insn:
>> (insn 6 5 7 3 cegcc-errno-bug.c:114 (set (reg/f:SI 138)
>> (symbol_ref:SI ("errno") [flags 0x4c0] > errno>)) -1 (nil))
>> cegcc-errno-bug.c:134: internal compiler error: in extract_insn, at
>> recog.c:2048
> 
>> Of course I could report a bug but since original sources are patched
the
>> bug might be due to one of the modifications.
>> And here is the testcase :
> 
>   You could probably have cut that down just to the definition of errno,
> Eet_Error and eet_flush2.  Which actual definition of EAPI were you
using?
> 
>> If I comment the errno variable inside the switch and replace it by 1
for
>> instance, it compiles fine.
>> Where should I start ?
> 
>   First thing would be to try and figure out why the insn isn't being
> recognized.  This is rather odd unless your patch has affected the movsi
> definition in the .md file.  Does the error go away if you make sure
there
> is
> no dllimport/export attribute?
> 
> cheers,
>   DaveK

Yes I think I forgot to apply some patch about dllimport/export.
That's the problem when maintaining something outside gcc trunk.
I will try to add the modification and test again.

Variable length arrays : aligned on stack

[Jean Christophe Beyler]

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)
{
long arr[512];
...
}

Simply moves the stack pointer 512*sizeof(long) bytes down.

I suppose this is a Machine Description problem but was wondering if
you had any tips on where to look?

Thanks for your help,
Jean Christophe Beyler

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

[Tom Tromey]

> "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 will
essentially give in to any demand from RMS.  It seems we have
collectively struck a bad deal that requires us to go against our own
better judgment... can we renegotiate?

Joe> Brad Kuhn said something to the effect that he considered RMS the
Joe> expert when it came to promoting the idea of free software, but
Joe> on technical matters RMS is just another developer.

That sounds like a better deal, but it isn't the one we actually have.
Instead it seems to me that we can only make certain kinds of progress
by neglecting to mention them to RMS.  Or has somebody told him about
C++ project yet?  :-)

Tom

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

[Tom Tromey]

> "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 member on the SC, someone who could summarize (to
the extent possible) SC happenings, much as the RMs do now for
releases.

Tom

Re: Typo or intended?

[Vladimir Makarov]

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 which we don't allow at -O1 because it is too expensive. After 
investigation, I found that it is the following new code causes the trouble. I don't 
quite understand the function of the new code, but I don't see what's special for -O1 
in terms of register allocation in comparison with higher optimizing levels. If I 
change it to (optimize < 1), everthing is fine as before. I start to wonder 
whether (optimize <= 1) is a typo or intended. Thanks in advance.

  

Sorry for the delay with the answer.  I was on vacation last week.

As Andrew Haley guess, it was intended.  I thought that improving 
debugging for -O1 is also important (more important than optimization).  
Although GCC manual says


With `-O', the compiler tries to reduce code size and execution
time, without performing any optimizations that take a great deal
of compilation time.

it also says

`-O' also turns on `-fomit-frame-pointer' on machines where doing
so does not interfere with debugging.

Therefore I've decided to do analogous thing for the patch.  May be I am 
wrong.  We could do this only for -O0 if people really want this which I 
am not sure about.

Cheers,
Bingfeng Mei
Broadcom UK

  if ((! flag_caller_saves && ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
  /* For debugging purposes don't put user defined variables in
 callee-clobbered registers.  */
	  || (optimize <= 1   <-  why include -O1? 
	  && (attrs = REG_ATTRS (regno_reg_rtx [ALLOCNO_REGNO (a)])) != NULL

  && (decl = attrs->decl) != NULL
  && VAR_OR_FUNCTION_DECL_P (decl)
  && ! DECL_ARTIFICIAL (decl)))
{
  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
call_used_reg_set);
  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
call_used_reg_set);
}
  else if (ALLOCNO_CALLS_CROSSED_NUM (a) != 0)
{
  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
no_caller_save_reg_set);
  IOR_HARD_REG_SET (ALLOCNO_TOTAL_CONFLICT_HARD_REGS (a),
temp_hard_reg_set);
  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
no_caller_save_reg_set);
  IOR_HARD_REG_SET (ALLOCNO_CONFLICT_HARD_REGS (a),
temp_hard_reg_set);
}
  

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

[Joe Buck]

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 to it?

It seemed the alternative was going to war over what we hoped would
be a temporary situation, and this was connected to a licensing issue.
I still haven't found out what happened this weekend, when RMS and
the lawyers were supposed to meet to decide whether the new license
draft (that addressed the problems that Ian listed) would be OK.

> I've seen other statements on this thread indicating that the SC will
> essentially give in to any demand from RMS.

Which isn't really correct, as I pointed out before: RMS objected to
keeping hosting the project on gcc.gnu.org.  He objected to the switch
to subversion.  He objected to the switch to bugzilla.  In all three
cases, the decision he did not prefer won.

> It seems we have
> collectively struck a bad deal that requires us to go against our own
> better judgment... can we renegotiate?

I think that we are going to have to work out a new understanding
after this episode.

> Joe> Brad Kuhn said something to the effect that he considered RMS the
> Joe> expert when it came to promoting the idea of free software, but
> Joe> on technical matters RMS is just another developer.
> 
> That sounds like a better deal, but it isn't the one we actually have.
> Instead it seems to me that we can only make certain kinds of progress
> by neglecting to mention them to RMS.  Or has somebody told him about
> C++ project yet?  :-)

To be more precise, Brad's been trying to convince RMS to think of himself
that way, particularly on issues that he doesn't really understand that
well.  And it certainly is true that it's easier to get forgiveness than
permission.

I know RMS knows about gold.

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

[Ian Lance Taylor]

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, and I very much
doubt that any of the other binutils maintainers did either.

While agreeing that the FSF is the legal owner of the code, I personally
consider the implementation language to be a technical detail which the
FSF has no special control over.  We can consider their input, but we
need not follow it.  This is distinct from licensing issues, where we
had to either move to GPLv3 or fork into an independent project.


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 because we could not continue operating under the
existing gcc maintainership regime, and we could not get the FSF to
change it.  We signed up most of the non-Cygnus contributors because we
needed political cover; we were able to sign them up because they were
facing the same problems that we were.

Ian

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

[Ian Lance Taylor]

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 you serious?  Why would it be handled that way?

It was because some developers were afraid that people would confuse
development snapshots with official releases.  Also, releases were made
more often back then.

I think the GNU binutils was the first GNU project to break that rule,
when Ken Raeburn started making weekly snapshots of the development tree
around 1994 or so.  He was following the lead of Linus and the kernel.

Ian

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

[Ian Lance Taylor]

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 off-topic, but why *is* gcc on sourceware.org?
>
> Because long ago, Cygnus (now part of Red Hat) contributed hosting for the
> egcs project, and it happens to be the same machine.  The egcs project
> had a very nice setup, and when egcs became GCC it was kept.

It's also worth noting that at the time the FSF had no serious
alternative.  The FSF wasn't providing CVS service for any projects, and
sourceware.org was much more reliable than the FSF servers at the time.
Nowadays we would consider using savannah.

Ian

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

[Ian Lance Taylor]

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 ask the FSF.  They
don't read this mailing list.

But, please don't ask.  At least not until this is all settled.  It will
just delay the process of working it out.

Ian

Re: Posix C++ integration

[Lawrence Crowl]

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
> respect to threads so I would like to propose the idea of making
> the C++ functions related to Posix threads reentrant. But i have
> some doubt regarding this as some functions are non-reentrant
> because they communicate across multiple function invocations by
> maintaining state information in static library-allocated storage,
> which is shared by all the threads of a process, possibly without
> the benefit of synchronization. Some other functions can be
> reentrant or non-reentrant depending upon there arguments. So
> i would like to ask whether the idea of making C++ functions
> related to threads reentrant is feasible enough to be proposed
> as a GSoC project?

Much of the work in producing a C++ interface to Posix involves
resolving differences between various standards and reaching
agreement between interested parties on the shape of the interface.
Most of that work has yet to be done.  Once that work is done,
though, the actual coding will be fairly easy.  So, I suggest
that Posix/C++ integration would not be good for a GSoC project.
A project that has a narrower scope and more code would be better.

-- 
Lawrence Crowl

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

[Joe Buck]

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 because we could not continue operating under the
> existing gcc maintainership regime, and we could not get the FSF to
> change it.  We signed up most of the non-Cygnus contributors because we
> needed political cover; we were able to sign them up because they were
> facing the same problems that we were.

Well, yes; egcs started with a proposal from inside Cygnus, and it started
from Cygnus's "devo tree".  But those people were wise enough to avoid a
simple Cygnus takeover.  Instead they chose people outside Cygnus to set
up a structure that provided some independence, and to create an effort
that would merge a bunch of code that wasn't in the FSF sources: the
Pentium gcc fork, HJ Lu's Linux patches, g77 as well as what Cygnus was
working on.

Re: GCC C FRONT END EXPLANATION

[Eduardo Cruz]

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 (parser);

so it consumes the token "(", and then calls c_parser_attributes to
check the parameters of the function

but in c_parser_attributes this is made in the beggining of the loop:

  c_parser_consume_token (parser);
  if (!c_parser_require (parser, CPP_OPEN_PAREN, "expected %<(%>"))
{
  parser->lex_untranslated_string = false;
  return attrs;
}

I don't understand, after the consumed token "(" there will be a
variable type right?
why it consumed the token without checking it?
and why does it require the token "(" ? aren't we inside the function
parameters list?

that's all for a while
thanks

2009/3/20 Dave Korn :
> Guilherme Puglia wrote:
>
>> But thanks to everybody.
>> I'll read the gcc docs in the source code!
>
>
>  The C parser starts in gcc/c-parser.c.  There are a bunch of lexing routines
> at the top, then you'll see a whole bunch of c_parser_X routines which
> handle the individual grammar constructs.  Each one has a commnent at the top
> describing the syntax elements it parses and referring to the paragraph of the
> C standard where they're defined.  (If you don't have a copy of the C standard
> handy, google "n1256.pdf").  Good luck!
>
>    cheers,
>      DaveK
>
>

Re: GCC C FRONT END EXPLANATION

[Ian Lance Taylor]

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 detail.  For background, see

http://gcc.gnu.org/onlinedocs/gcc-4.3.3/gcc/Function-Attributes.html

Ian

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

[Jeff Law]

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 you see between how GCC 
developers and other people think about FOSS?  I'm curious about your 
perception here, and what basis it is grounded on.


I'd divide customers into two broad camps.  Both camps are extremely 
pragmatic, but they're focused on two totally different goals.


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 which 
drive processor & embedded kit sales.   The key for these guys is free, 
as in beer, widely available tools.  The fact that the compiler & 
assorted utilities are open-source is largely irrelevant.


The second broad camp I run into regularly are software developers 
themselves building applications, most often for internal use, but 
occasionally they're building software that is then licensed to their 
customers.  They'd probably describe the compiler & associated utilities 
as a set of hammers, screwdrivers and the like -- they're just as happy 
using GCC as any other compiler so long as it works.  The fact that the 
GNU tools are open source is completely irrelevant to these guys.  They 
want to see standards compliance, abi interoperability, and 
interoperability with other tools (such as debuggers, profilers, guis, 
etc).  They're more than willing to swap out one set of tools for 
another if it gives them some advantage.  Note that an advantage isn't 
necessarily compile-time or runtime performance -- it might be ease of 
use, which they believe allows their junior level engineers to be more 
effective (this has come up consistently over the last few years).


Note that in neither case do they really care about the open-source 
aspects of their toolchain (or for the most part the OS either).   They 
may (and often do) like the commoditization of software that FOSS tends 
to drive, but don't mistake that for caring about the open source ideals 
-- it's merely cost-cutting.


While I often encounter individual engineers or managers within these 
organizations who care about the FOSS ideals and have helped drive FOSS 
into those organizations; it's usually not pervasive in those 
organizations, even those who have had good success with FOSS platforms.


I don't know if that answers your question or not.

Jeff

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

[Dave Korn]

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 which
> drive processor & embedded kit sales.   The key for these guys is free,
> as in beer, widely available tools.  The fact that the compiler &
> assorted utilities are open-source is largely irrelevant.

  That depends!  The fact that the toolchain is open-source means we can
maintain and bugfix our releases and provide feature enhancements to better
support our customers.  If we bought in a proprietary closed compiler we'd be
critically dependent on the quality of the supplier's support in order to
ensure the growth of that eco-system, an externality we might well want to
avoid predicating our success upon.

cheers,
  DaveK

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

[Jeff Law]

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 consumable devices which
drive processor & embedded kit sales.   The key for these guys is free,
as in beer, widely available tools.  The fact that the compiler &
assorted utilities are open-source is largely irrelevant.



  That depends!  The fact that the toolchain is open-source means we can
maintain and bugfix our releases and provide feature enhancements to better
support our customers.  If we bought in a proprietary closed compiler we'd be
critically dependent on the quality of the supplier's support in order to
ensure the growth of that eco-system, an externality we might well want to
avoid predicating our success upon.
  
I'm referring to the customers where I've personally spent time 
discussing tools issues.  Obviously there are exceptions and 
organizations where other motivations come in to play,  or are so big 
that they have sub-organizations which look at things from totally 
different viewpoints.  And (of course) I won't claim to have met every 
organization of importance, far from it.




jeff