why are these alias sets different?

why are these alias sets different?

[Zack Weinberg]

I'm experimenting with aliasing warnings.  My current patch warns way
too much; it appears to be because compatible types sometimes get
distinct alias sets anyway.  For example:

(gdb) p type
$1 = 0x8364fb8
(gdb) pt
 <pointer_type 0x8364fb8
    type <integer_type 0x8322090 unsigned char allocated from permanent_obstack
	unsigned permanent QI
	size <integer_cst 0x8321fd0 constant permanent 8>
	align 8 symtab 11 alias set -1 precision 8
	min <integer_cst 0x83220f0 constant permanent 0>
	max <integer_cst 0x8322108 constant permanent 255>
	pointer_to_this <pointer_type 0x8364fb8>>
    allocated from permanent_obstack
    unsigned permanent SI
    size <integer_cst 0x8322360 type <integer_type 0x832787c unsigned int>
	  constant permanent 32>
    align 32 symtab 0 alias set 17>
(gdb) p otype
$2 = 0x832856c
(gdb) pt
 <pointer_type 0x832856c
    type <integer_type 0x8322120 char allocated from permanent_obstack
	permanent QI
	size <integer_cst 0x8321fd0 constant permanent 8>
	align 8 symtab 2 alias set 0 precision 8
	min <integer_cst 0x8322180 constant permanent -128>
	max <integer_cst 0x8322198 constant permanent 127>
	pointer_to_this <pointer_type 0x832856c>>
    allocated from permanent_obstack
    unsigned permanent SI
    size <integer_cst 0x8322360 type <integer_type 0x832787c unsigned int>
	  constant permanent 32>
    align 32 symtab 63 alias set 4>

Why do these have different alias sets, and how do I work around that?

I'm inside build_c_cast here and the containing expression tree is

<postincrement_expr 0x8323600
    type <pointer_type 0x832856c
	type <integer_type 0x8322120 char allocated from permanent_obstack
	    permanent QI
	    size <integer_cst 0x8321fd0 constant permanent 8>
	    align 8 symtab 2 alias set 0 precision 8
	    min <integer_cst 0x8322180 constant permanent -128>
	    max <integer_cst 0x8322198 constant permanent 127>
	    pointer_to_this <pointer_type 0x832856c>>
	allocated from permanent_obstack
	unsigned permanent SI
	size <integer_cst 0x8322360 constant permanent 32>
	align 32 symtab 63 alias set 4>
    allocated from momentary_obstack
    side-effects
    arg 0 <component_ref 0x8323578 type <pointer_type 0x832856c>
	allocated from momentary_obstack
       
	arg 0 <indirect_ref 0x8323564 type <record_type 0x834b3b8 _IO_FILE>
	    allocated from momentary_obstack
	    arg 0 <parm_decl 0x8364e20 __fp>>
	arg 1 <field_decl 0x834caf8 _IO_read_ptr type <pointer_type 0x832856c>
	    allocated from permanent_obstack
	    unsigned permanent in_system_header SI
	    file /usr/include/libio.h line 195 size <integer_cst 0x8322360 32>
	    align 32
	    bitpos <integer_cst 0x83384a8 constant permanent 32>
	    context <record_type 0x834b3b8 _IO_FILE>
	    arguments <integer_cst 0x83384a8 32>
	    chain <field_decl 0x834cbd4 _IO_read_end>>>
    arg 1 <integer_cst 0x83235e8 type <pointer_type 0x832856c> constant 1>>

The source code that provoked this was

extern __inline int
getc_unlocked (FILE *__fp)  
{
  return ((__fp)->_IO_read_ptr >= (__fp)->_IO_read_end
	  ? __uflow (__fp)
	  : *(unsigned char *) (__fp)->_IO_read_ptr++);
}

_IO_read_ptr is plain char *.

zw

Re: why are these alias sets different?

[Mark Mitchell]

Zack --

  `char' and `unsigned char' will wind up in the same alias set.  The
-1 on `unsigned char' just means that it doesn't have an alias set
yet.

  And `char *' and `unsigned char *' are not compatible types, which
is why they don't have the same alias set.  You can't say:

  unsigned char c;
  char *p;
  unsigned char **pp = (unsigned char **) &p;
  *pp = &c;

for example, in a conforming program.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: why are these alias sets different?

[Zack Weinberg]

Mark Mitchell wrote:
> 
> Zack --
> 
>   `char' and `unsigned char' will wind up in the same alias set.  The
> -1 on `unsigned char' just means that it doesn't have an alias set
> yet.

*nod*

>   And `char *' and `unsigned char *' are not compatible types, which
> is why they don't have the same alias set.  You can't say:
> 
>   unsigned char c;
>   char *p;
>   unsigned char **pp = (unsigned char **) &p;
>   *pp = &c;

Thanks. I guess I should strip off exactly one layer of POINTER_TYPE
nodes and then do the comparison, special casing void * and char *.

Am I right to think that alias sets have nothing to do with the
base-pointer alias code?

zw

Re: why are these alias sets different?

[Mark Mitchell]

>>>>> "Zack" == Zack Weinberg <zack@bitmover.com> writes:
    >> And `char *' and `unsigned char *' are not compatible types,
    >> which is why they don't have the same alias set.  You can't
    >> say:
    >> 
    >> unsigned char c; char *p; unsigned char **pp = (unsigned char
    >> **) &p; *pp = &c;

    Zack> Thanks. I guess I should strip off exactly one layer of
    Zack> POINTER_TYPE nodes and then do the comparison, special
    Zack> casing void * and char *.

Sounds rightish.  I don't know exactly where you're putting the
warning.  If you do it the way RMS was suggesting, in alias.c, then
you shouldn't have to strip anything at all.  Just call
different_alias_sets or whatever, but after the base alias check has
been done, and warn if it says the alias sets are different but the
base alias check says the memory is the same.  If you're doing it
closer to the source, where you're likely to get more coherent warning
messages, then you probably need to strip one level of pointer; when
you see a store through `int **', and want to know if that aliases a
thing of type `double *', you compare `int *' and `double *'.

    Zack> Am I right to think that alias sets have nothing to do with
    Zack> the base-pointer alias code?

Yes.  

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: why are these alias sets different?

[Zack Weinberg]

Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zack@bitmover.com> writes:
>     >> And `char *' and `unsigned char *' are not compatible types,
>     >> which is why they don't have the same alias set.  You can't
>     >> say:
>     >> 
>     >> unsigned char c; char *p; unsigned char **pp = (unsigned char
>     >> **) &p; *pp = &c;
> 
>     Zack> Thanks. I guess I should strip off exactly one layer of
>     Zack> POINTER_TYPE nodes and then do the comparison, special
>     Zack> casing void * and char *.
> 
> Sounds rightish.  I don't know exactly where you're putting the
> warning.  If you do it the way RMS was suggesting, in alias.c, then
> you shouldn't have to strip anything at all.  Just call
> different_alias_sets or whatever, but after the base alias check has
> been done, and warn if it says the alias sets are different but the
> base alias check says the memory is the same.  If you're doing it
> closer to the source, where you're likely to get more coherent warning
> messages, then you probably need to strip one level of pointer; when
> you see a store through `int **', and want to know if that aliases a
> thing of type `double *', you compare `int *' and `double *'.

I'm implementing the suggestion that Nick? made, to warn when we see a
cast between pointers in different alias sets.  This is easy (just a
few lines in c-typeck.c), close enough to source that we get sane line
numbers, and I think it'll be reasonably accurate.  I have it working
except for the union-type extension, which should only warn with
-pedantic.

zw

Re: why are these alias sets different?

[Mark Mitchell]

>>>>> "Zack" == Zack Weinberg <zack@bitmover.com> writes:

    Zack> I'm implementing the suggestion that Nick? made, to warn
    Zack> when we see a cast between pointers in different alias sets.
    Zack> This is easy (just a few lines in c-typeck.c), close enough
    Zack> to source that we get sane line numbers, and I think it'll
    Zack> be reasonably accurate.  I have it working except for the
    Zack> union-type extension, which should only warn with -pedantic.

That's certainly worth a try.  I don't know how many false positives
we'll see, but if it's not too many this will be a useful warning.
Definitely you can give a more helpful warning-message than with the
RMS suggestion (at least without a major effort).

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: why are these alias sets different?

[Nick Ing-Simmons]

Mark Mitchell <mark@codesourcery.com> writes:
>>>>>> "Zack" == Zack Weinberg <zack@bitmover.com> writes:
>
>    Zack> I'm implementing the suggestion that Nick? 
>    made, to warn

I asked for warnings, but I was not specific about how or where they 
were implemented.

>    Zack> when we see a cast between pointers in different alias sets.
>    Zack> This is easy (just a few lines in c-typeck.c), close enough
>    Zack> to source that we get sane line numbers, and I think it'll
>    Zack> be reasonably accurate.  I have it working except for the
>    Zack> union-type extension, which should only warn with -pedantic.
>
>That's certainly worth a try.  I don't know how many false positives
>we'll see, but if it's not too many this will be a useful warning.

Right now, I would not mind a a lot of false positives so long as number 
of warnings is less than number of lines in the file - it would still help 
tracking down bugs in the large body of code written by many people that 
is perl...

>Definitely you can give a more helpful warning-message than with the
>RMS suggestion (at least without a major effort).

If RMS's suggestion was to add a warning when generated code differed because 
of aliasing assumptions then that would be a help too - even if it only 
points at function.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: why are these alias sets different?

[Jamie Lokier]

Zack Weinberg <zack@bitmover.com> wrote:
>> I'm implementing the suggestion that Nick? made, to warn

Nick Ing-Simmons wrote:
> I asked for warnings, but I was not specific about how or where they 
> were implemented.

It was me.  The suggestion about comparing alias sets was about the
third or fourth attempt discussed here.  The earlier ones gave too many
false positives.

-- Jamie

Re: why are these alias sets different?

[Nick Ing-Simmons]

Mark Mitchell <mark@codesourcery.com> writes:
>>>>>> "Zack" == Zack Weinberg <zack@bitmover.com> writes:
>
>    Zack> I'm implementing the suggestion that Nick? 
>    made, to warn

I asked for warnings, but I was not specific about how or where they 
were implemented.

>    Zack> when we see a cast between pointers in different alias sets.
>    Zack> This is easy (just a few lines in c-typeck.c), close enough
>    Zack> to source that we get sane line numbers, and I think it'll
>    Zack> be reasonably accurate.  I have it working except for the
>    Zack> union-type extension, which should only warn with -pedantic.
>
>That's certainly worth a try.  I don't know how many false positives
>we'll see, but if it's not too many this will be a useful warning.

Right now, I would not mind a a lot of false positives so long as number 
of warnings is less than number of lines in the file - it would still help 
tracking down bugs in the large body of code written by many people that 
is perl...

>Definitely you can give a more helpful warning-message than with the
>RMS suggestion (at least without a major effort).

If RMS's suggestion was to add a warning when generated code differed because 
of aliasing assumptions then that would be a help too - even if it only 
points at function.

-- 
Nick Ing-Simmons <nik@tiuk.ti.com>
Via, but not speaking for: Texas Instruments Ltd.

Re: why are these alias sets different?

[Mark Mitchell]

Zack --

  `char' and `unsigned char' will wind up in the same alias set.  The
-1 on `unsigned char' just means that it doesn't have an alias set
yet.

  And `char *' and `unsigned char *' are not compatible types, which
is why they don't have the same alias set.  You can't say:

  unsigned char c;
  char *p;
  unsigned char **pp = (unsigned char **) &p;
  *pp = &c;

for example, in a conforming program.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: why are these alias sets different?

[Zack Weinberg]

Mark Mitchell wrote:
> 
> Zack --
> 
>   `char' and `unsigned char' will wind up in the same alias set.  The
> -1 on `unsigned char' just means that it doesn't have an alias set
> yet.

*nod*

>   And `char *' and `unsigned char *' are not compatible types, which
> is why they don't have the same alias set.  You can't say:
> 
>   unsigned char c;
>   char *p;
>   unsigned char **pp = (unsigned char **) &p;
>   *pp = &c;

Thanks. I guess I should strip off exactly one layer of POINTER_TYPE
nodes and then do the comparison, special casing void * and char *.

Am I right to think that alias sets have nothing to do with the
base-pointer alias code?

zw

Re: why are these alias sets different?

[Jamie Lokier]

Zack Weinberg <zack@bitmover.com> wrote:
>> I'm implementing the suggestion that Nick? made, to warn

Nick Ing-Simmons wrote:
> I asked for warnings, but I was not specific about how or where they 
> were implemented.

It was me.  The suggestion about comparing alias sets was about the
third or fourth attempt discussed here.  The earlier ones gave too many
false positives.

-- Jamie

Re: why are these alias sets different?

[Mark Mitchell]

>>>>> "Zack" == Zack Weinberg <zack@bitmover.com> writes:
    >> And `char *' and `unsigned char *' are not compatible types,
    >> which is why they don't have the same alias set.  You can't
    >> say:
    >> 
    >> unsigned char c; char *p; unsigned char **pp = (unsigned char
    >> **) &p; *pp = &c;

    Zack> Thanks. I guess I should strip off exactly one layer of
    Zack> POINTER_TYPE nodes and then do the comparison, special
    Zack> casing void * and char *.

Sounds rightish.  I don't know exactly where you're putting the
warning.  If you do it the way RMS was suggesting, in alias.c, then
you shouldn't have to strip anything at all.  Just call
different_alias_sets or whatever, but after the base alias check has
been done, and warn if it says the alias sets are different but the
base alias check says the memory is the same.  If you're doing it
closer to the source, where you're likely to get more coherent warning
messages, then you probably need to strip one level of pointer; when
you see a store through `int **', and want to know if that aliases a
thing of type `double *', you compare `int *' and `double *'.

    Zack> Am I right to think that alias sets have nothing to do with
    Zack> the base-pointer alias code?

Yes.  

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

why are these alias sets different?

[Zack Weinberg]

I'm experimenting with aliasing warnings.  My current patch warns way
too much; it appears to be because compatible types sometimes get
distinct alias sets anyway.  For example:

(gdb) p type
$1 = 0x8364fb8
(gdb) pt
 <pointer_type 0x8364fb8
    type <integer_type 0x8322090 unsigned char allocated from permanent_obstack
	unsigned permanent QI
	size <integer_cst 0x8321fd0 constant permanent 8>
	align 8 symtab 11 alias set -1 precision 8
	min <integer_cst 0x83220f0 constant permanent 0>
	max <integer_cst 0x8322108 constant permanent 255>
	pointer_to_this <pointer_type 0x8364fb8>>
    allocated from permanent_obstack
    unsigned permanent SI
    size <integer_cst 0x8322360 type <integer_type 0x832787c unsigned int>
	  constant permanent 32>
    align 32 symtab 0 alias set 17>
(gdb) p otype
$2 = 0x832856c
(gdb) pt
 <pointer_type 0x832856c
    type <integer_type 0x8322120 char allocated from permanent_obstack
	permanent QI
	size <integer_cst 0x8321fd0 constant permanent 8>
	align 8 symtab 2 alias set 0 precision 8
	min <integer_cst 0x8322180 constant permanent -128>
	max <integer_cst 0x8322198 constant permanent 127>
	pointer_to_this <pointer_type 0x832856c>>
    allocated from permanent_obstack
    unsigned permanent SI
    size <integer_cst 0x8322360 type <integer_type 0x832787c unsigned int>
	  constant permanent 32>
    align 32 symtab 63 alias set 4>

Why do these have different alias sets, and how do I work around that?

I'm inside build_c_cast here and the containing expression tree is

<postincrement_expr 0x8323600
    type <pointer_type 0x832856c
	type <integer_type 0x8322120 char allocated from permanent_obstack
	    permanent QI
	    size <integer_cst 0x8321fd0 constant permanent 8>
	    align 8 symtab 2 alias set 0 precision 8
	    min <integer_cst 0x8322180 constant permanent -128>
	    max <integer_cst 0x8322198 constant permanent 127>
	    pointer_to_this <pointer_type 0x832856c>>
	allocated from permanent_obstack
	unsigned permanent SI
	size <integer_cst 0x8322360 constant permanent 32>
	align 32 symtab 63 alias set 4>
    allocated from momentary_obstack
    side-effects
    arg 0 <component_ref 0x8323578 type <pointer_type 0x832856c>
	allocated from momentary_obstack
       
	arg 0 <indirect_ref 0x8323564 type <record_type 0x834b3b8 _IO_FILE>
	    allocated from momentary_obstack
	    arg 0 <parm_decl 0x8364e20 __fp>>
	arg 1 <field_decl 0x834caf8 _IO_read_ptr type <pointer_type 0x832856c>
	    allocated from permanent_obstack
	    unsigned permanent in_system_header SI
	    file /usr/include/libio.h line 195 size <integer_cst 0x8322360 32>
	    align 32
	    bitpos <integer_cst 0x83384a8 constant permanent 32>
	    context <record_type 0x834b3b8 _IO_FILE>
	    arguments <integer_cst 0x83384a8 32>
	    chain <field_decl 0x834cbd4 _IO_read_end>>>
    arg 1 <integer_cst 0x83235e8 type <pointer_type 0x832856c> constant 1>>

The source code that provoked this was

extern __inline int
getc_unlocked (FILE *__fp)  
{
  return ((__fp)->_IO_read_ptr >= (__fp)->_IO_read_end
	  ? __uflow (__fp)
	  : *(unsigned char *) (__fp)->_IO_read_ptr++);
}

_IO_read_ptr is plain char *.

zw

Re: why are these alias sets different?

[Zack Weinberg]

Mark Mitchell wrote:
> >>>>> "Zack" == Zack Weinberg <zack@bitmover.com> writes:
>     >> And `char *' and `unsigned char *' are not compatible types,
>     >> which is why they don't have the same alias set.  You can't
>     >> say:
>     >> 
>     >> unsigned char c; char *p; unsigned char **pp = (unsigned char
>     >> **) &p; *pp = &c;
> 
>     Zack> Thanks. I guess I should strip off exactly one layer of
>     Zack> POINTER_TYPE nodes and then do the comparison, special
>     Zack> casing void * and char *.
> 
> Sounds rightish.  I don't know exactly where you're putting the
> warning.  If you do it the way RMS was suggesting, in alias.c, then
> you shouldn't have to strip anything at all.  Just call
> different_alias_sets or whatever, but after the base alias check has
> been done, and warn if it says the alias sets are different but the
> base alias check says the memory is the same.  If you're doing it
> closer to the source, where you're likely to get more coherent warning
> messages, then you probably need to strip one level of pointer; when
> you see a store through `int **', and want to know if that aliases a
> thing of type `double *', you compare `int *' and `double *'.

I'm implementing the suggestion that Nick? made, to warn when we see a
cast between pointers in different alias sets.  This is easy (just a
few lines in c-typeck.c), close enough to source that we get sane line
numbers, and I think it'll be reasonably accurate.  I have it working
except for the union-type extension, which should only warn with
-pedantic.

zw

Re: why are these alias sets different?

[Mark Mitchell]

>>>>> "Zack" == Zack Weinberg <zack@bitmover.com> writes:

    Zack> I'm implementing the suggestion that Nick? made, to warn
    Zack> when we see a cast between pointers in different alias sets.
    Zack> This is easy (just a few lines in c-typeck.c), close enough
    Zack> to source that we get sane line numbers, and I think it'll
    Zack> be reasonably accurate.  I have it working except for the
    Zack> union-type extension, which should only warn with -pedantic.

That's certainly worth a try.  I don't know how many false positives
we'll see, but if it's not too many this will be a useful warning.
Definitely you can give a more helpful warning-message than with the
RMS suggestion (at least without a major effort).

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

[Fwd: Re: [gnu.org #6139] Linux New Media Award 2002]

[Rosemarie Schuster]

[-- Attachment #1: Type: text/plain, Size: 1466 bytes --]

Dear GCC Team,

for the third year in a row the Linux New Media Awards are being
presented.

Our Editor's Choice Award is different from other magazine awards in
that in addition to the editors, a jury of authors, industry leaders and
members of the development and 
Open Source Community participated in the voting.

In the categorie for "Development Software" GCC has been nominated.
Congratulations, GCC has been voted as the best Development Software.

Please let us know who is the right person at your company to address
the award to. 

For further information, please see the enclosed press information
including the list of all categories and winners.

Thank you for your response!

Rosemarie Schuster



-------- Original Message --------
Subject: Re: [gnu.org #6139] Linux New Media Award 2002
Date: Wed, 06 Nov 2002 19:07:06 -0500
From: "FSF General Contact Address via RT" <info@fsf.org>
Reply-To: info@fsf.org
To: rschuster@linuxnewmedia.de


On Wed, Nov 06, 2002 at 03:53:00AM -0500, Rosemarie Schuster via RT
wrote:
> In the categorie for "Development Software" GCC has been nominated.
> Congratulations, GCC has been voted as the best mobile Linux device.

Dear Rosemarie,

Please write to the GCC developers with your request for information;
you
can reach them by mailing <gcc@gcc.gnu.org>.

Best regards,

-- 
Brett Smith
Free Software Foundation

Help support our work for the FSF and the GNU project:
     http://svcs.affero.net/rm.php?r=fsfinfo

[-- Attachment #2: lnm_award.txt --]
[-- Type: text/plain, Size: 3920 bytes --]

Jury Chooses 2002 Linux New Media Award Winners

Munich, Germany. November 5, 2002

With its annual Awards, Linux New Media recognizes the products, 
projects and companies that have done the most to promote free 
software and advance the use of Linux worldwide.

In each of 10 categories, the first, second, and third places were 
determined by vote of a 35-person jury. The jury was made up of Linux 
professionals including the editorial teams of and regular 
contributors to Linux Magazine, Linux-Magazin, LinuxUser, and 
Linux-Community.de. Further jury members included VIPs of the Open 
Source scene and Linux business such as Kernel Coordinator Alan Cox, 
Linux International President Jon "maddog" Hall, 
FreeSoftwareFoundation Europe's President Georg Greve, IBM Linux 
Evangelist Tom Schwaller, and Kalle Dalheimer, one of the founder of 
the KDE Project.

The winners: 

The Linux PDA Sharp Zaurus won the Mobile Devices category, while the 
Network Hardware award went to the Axiom AX 6113 server. Pioneer's 
DVR-104 DVD Writer hit the top spot for General Hardware. Under Linux 
Distributions, it is no surprise that Debian won the race - the jury 
honored the work of several key developers who have worked so hard on 
the free operating system over the past years. The GCC ("GNU Compiler 
Collection", renamed from "GNU C Compiler" in 1999) won the award for 
the best Development Software. In the Office Packages category, the 
Open Office suite prevailed against the other competitors with a 
sensational vote of 47.8%.

Mozilla triumphed over the email client Mutt and Konqueror browser to 
win under Internet Applications. In the Databases category, 
PostgreSQL overtook MySQL for the first time. The special award for 
Newcomer of the Year goes to Gentoo Linux, a BSD-style, ports-based 
distribution that allows users to build all packages specifically for 
a particular machine. In the Linux Companies category, IBM won the 
first prize as the company who has done the most to promote Linux 
during the past year.

And the winners in detail are:

Hardware
Mobile Devices
1. Sharp Zaurus 		44%
2. Compaq Ipq   		31%
3. Yopy 			25%

Hardware components
1. Axiom AX 6113  		34,9%
2. Intranator    		30,9%
3. Equiinet     		23,3%

Network Hardware
1. Pioneer DVR-104	23,9%
2. ATI FireGL 		4 23,1%
3. Fujitsu Siemens Memorybird   14,6%

Software
Distributions
1. Debian       		28,8%
2. Knoppix      		25,7%
3. SuSE 			13,1%

Development Software
1. GCC  			25,5%
2. KDevelop     		15,2%
3. Eclipse      		13,6%

Office Packages
1. Open Office  		47,8%
2. KOffice      		11,3%
3. Star Office  		10,1%

Internet Clients
1. Mozilla      		29,4%
2. Mutt 			17,2%
3. Konqueror    		16,7%

Databases
1. PostgreSQL   		39,6%
2. MySQL        		33,7%
3. DB2  			  9,5%

Special Award
Newcomer of the year
1. Gentoo       		24,4%
1. Ogg Vorbis   		24,4%
2. Video Disk Recorder  	17,2%

Companies who have been especially good for Linux
1. IBM  			33,5%
2. O'Reilly     		15,6%
3. Red Hat      		11,0%


About Linux New Media:
Linux New Media AG is the market leader for print and online Linux 
content in Europe. For over eight years, Linux New Media has been 
providing useful information on this unique Open Source operating 
system on a monthly basis.

Linux New Media publishes the international Linux-Magazine in English 
as well as the German-language publications Linux-Magazin and 
LinuxUser. Our website www.linux-community.de is a central forum 
where people interested in Linux can easily access extensive archives 
of news and information. In addition, Linux New Media further serves 
the Linux community by organizing Linux events such as the LinuxPark 
at the CeBIT.

For further information please contact:
Linux New Media AG
Stefan-George-Ring 24
81929 MÃŒnchen
Germany
Contact:  Birgit Claussen
Phone: +49-89 / 99 34 11 - 23
Fax: +49 -89 / 99 34 11 - 99
E-Mail: mailto:presse@linuxnewmedia.de


[-- Attachment #3: lnm_award_logo.jpg --]
[-- Type: image/jpeg, Size: 8713 bytes --]

Re: [Fwd: Re: [gnu.org #6139] Linux New Media Award 2002]

[Fergus Henderson]

On 25-Nov-2002, Rosemarie Schuster <rschuster@linuxnewmedia.de> wrote:
> 
> Please let us know who is the right person at your company to address
> the award to. 

It's very hard to nominate a single person, since GCC is the product
of work by a large number of people.

However, perhaps Mark Mitchell <mark@codesourcery.com>, who has been
the release manager for the last few releases of GCC, would be willing
to receive the award.

P.S.
Please don't take up too much of his time!

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: [Fwd: Re: [gnu.org #6139] Linux New Media Award 2002]

[Mark Mitchell]

--On Thursday, November 28, 2002 12:35:21 AM +1100 Fergus Henderson 
<fjh@cs.mu.OZ.AU> wrote:

> On 25-Nov-2002, Rosemarie Schuster <rschuster@linuxnewmedia.de> wrote:
>>
>> Please let us know who is the right person at your company to address
>> the award to.
>
> It's very hard to nominate a single person, since GCC is the product
> of work by a large number of people.
>
> However, perhaps Mark Mitchell <mark@codesourcery.com>, who has been
> the release manager for the last few releases of GCC, would be willing
> to receive the award.

GCC is bigger than any one of us.

I think the award should go directly to the FSF; the FSF is the
organization best associated with GCC.

Rosemarie, I suggest you contact the FSF directly; see:

  http://www.gnu.org

for information about how to get in touch with them.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: [Fwd: Re: [gnu.org #6139] Linux New Media Award 2002]

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> GCC is bigger than any one of us.

Mark> I think the award should go directly to the FSF; the FSF is the
Mark> organization best associated with GCC.

Mark> Rosemarie, I suggest you contact the FSF directly; see:

Mark> http://www.gnu.org

Mark> for information about how to get in touch with them.

	If you look at the message Rosemarie forwarded, info@gnu.org
redirected them to this mailinglist.  But I do not know why the FSF did
not handle this internally.

David

Re: [Fwd: Re: [gnu.org #6139] Linux New Media Award 2002]

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> GCC is bigger than any one of us.

Mark> I think the award should go directly to the FSF; the FSF is the
Mark> organization best associated with GCC.

Mark> Rosemarie, I suggest you contact the FSF directly; see:

Mark> http://www.gnu.org

Mark> for information about how to get in touch with them.

	If you look at the message Rosemarie forwarded, info@gnu.org
redirected them to this mailinglist.  But I do not know why the FSF did
not handle this internally.

David

A trouble with libssp in one-tree builds

[Kazu Hirata]

Hi Jakub,

I am having a trouble with libssp in one-tree builds.  That is, if I
try to build binutils and gcc at the same time, libssp/configure
complains while compiling (and linking) the following program and the
build process stops.

/* confdefs.h.  */

#define PACKAGE_NAME "libssp"
#define PACKAGE_TARNAME "libssp"
#define PACKAGE_VERSION "1.0"
#define PACKAGE_STRING "libssp 1.0"
#define PACKAGE_BUGREPORT ""
#define PACKAGE "libssp"
#define VERSION "1.0"
/* end confdefs.h.  */

int
main ()
{

  ;
  return 0;
}

The problem is that libssp/configure contains a link test, but we may
not have crt0.o built yet (assuming targets like h8300-elf,
arm-none-eabi, etc).

Is there anyway we could stop configuring libssp in this kind of case?
Or somehow work around the link test?  FWIW, I am sitting on the
attached patch to disable libssp for now.

Kazu Hirata

Index: configure.in
===================================================================
RCS file: /home/gcc/repos/gcc/gcc/configure.in,v
retrieving revision 1.355
diff -u -d -p -r1.355 configure.in
--- configure.in	2 Jul 2005 08:50:56 -0000	1.355
+++ configure.in	4 Jul 2005 04:42:35 -0000
@@ -307,6 +307,14 @@ if test "${ENABLE_LIBADA}" != "yes" ; th
   noconfigdirs="$noconfigdirs gnattools"
 fi
 
+AC_ARG_ENABLE(libssp,
+[  --enable-libssp        Builds libssp directory],
+ENABLE_LIBSSP=$enableval,
+ENABLE_LIBSSP=yes)
+if test "${ENABLE_LIBSSP}" != "yes" ; then
+  noconfigdirs="$noconfigdirs configure-target-libssp target-libssp"
+fi
+
 # Save it here so that, even in case of --enable-libgcj, if the Java
 # front-end isn't enabled, we still get libgcj disabled.
 libgcj_saved=$libgcj

Re: A trouble with libssp in one-tree builds

[Andrew Pinski]

On Jul 5, 2005, at 12:50 AM, Kazu Hirata wrote:

> Hi Jakub,
>
> I am having a trouble with libssp in one-tree builds.  That is, if I
> try to build binutils and gcc at the same time, libssp/configure
> complains while compiling (and linking) the following program and the
> build process stops.

I don't see anything different between this or libstdc++ or libobjc, or
any target library in libssp's configure.ac at all.

-- Pinski

Re: A trouble with libssp in one-tree builds

[Jakub Jelinek]

On Mon, Jul 04, 2005 at 09:50:08PM -0700, Kazu Hirata wrote:
> I am having a trouble with libssp in one-tree builds.  That is, if I
> try to build binutils and gcc at the same time, libssp/configure
> complains while compiling (and linking) the following program and the
> build process stops.
> 
> /* confdefs.h.  */
> 
> #define PACKAGE_NAME "libssp"
> #define PACKAGE_TARNAME "libssp"
> #define PACKAGE_VERSION "1.0"
> #define PACKAGE_STRING "libssp 1.0"
> #define PACKAGE_BUGREPORT ""
> #define PACKAGE "libssp"
> #define VERSION "1.0"
> /* end confdefs.h.  */
> 
> int
> main ()
> {
> 
>   ;
>   return 0;
> }
> 
> The problem is that libssp/configure contains a link test, but we may
> not have crt0.o built yet (assuming targets like h8300-elf,
> arm-none-eabi, etc).

DJ, can this be solved by toplevel Makefile.in's dependencies or
lang_env_dependencies?

	Jakub

Re: A trouble with libssp in one-tree builds

[Daniel Jacobowitz]

On Tue, Jul 05, 2005 at 03:27:23AM -0400, Jakub Jelinek wrote:
> > The problem is that libssp/configure contains a link test, but we may
> > not have crt0.o built yet (assuming targets like h8300-elf,
> > arm-none-eabi, etc).
> 
> DJ, can this be solved by toplevel Makefile.in's dependencies or
> lang_env_dependencies?

No.  You could arrange for libssp to depend on newlib, but that would
only help for in-tree builds; we build newlib out of tree, because we
also support glibc builds, so we try to keep the two fairly similar.

I think we need to finally come up with a way to build the compiler and
libraries at different times.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: A trouble with libssp in one-tree builds

[Mark Mitchell]

Daniel Jacobowitz wrote:
> On Tue, Jul 05, 2005 at 03:27:23AM -0400, Jakub Jelinek wrote:
> 
>>>The problem is that libssp/configure contains a link test, but we may
>>>not have crt0.o built yet (assuming targets like h8300-elf,
>>>arm-none-eabi, etc).
>>
>>DJ, can this be solved by toplevel Makefile.in's dependencies or
>>lang_env_dependencies?
> 
> 
> No.  You could arrange for libssp to depend on newlib, but that would
> only help for in-tree builds; we build newlib out of tree, because we
> also support glibc builds, so we try to keep the two fairly similar.
> 
> I think we need to finally come up with a way to build the compiler and
> libraries at different times.

Yes, definitely.  It sounds like libssp has broken the "traditional" 
build model in which you build compilers, then build newlib, and then 
build compilers and libraries.  At the very least, we need a 
--disable-libssp option, if that doesn't already exist.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: A trouble with libssp in one-tree builds

[David Edelsohn]

> At the very least, we need a 
> --disable-libssp option, if that doesn't already exist.

	This also is needed for targets that do not support libssp.  I
have had to disable building libssp on AIX using noconfigdirs because it
crashes the linker when building other libraries, I think because libssp
is added to the LIBPATH.

David

Re: A trouble with libssp in one-tree builds

[DJ Delorie]

> DJ, can this be solved by toplevel Makefile.in's dependencies or
> lang_env_dependencies?

The usual solution is to test $with_newlib and hard-code known results
if it's set.

You CANNOT rely on being able to link target programs in all cases.
It's better if you can figure out a non-linking test to use instead.

Re: A trouble with libssp in one-tree builds

[Andrew Pinski]

On Jul 5, 2005, at 2:31 PM, DJ Delorie wrote:

>
>> DJ, can this be solved by toplevel Makefile.in's dependencies or
>> lang_env_dependencies?
>
> The usual solution is to test $with_newlib and hard-code known results
> if it's set.
>
> You CANNOT rely on being able to link target programs in all cases.
> It's better if you can figure out a non-linking test to use instead.

We are just testing if the c compiler can compile.  Nothing more at this
point.  I should point out other target libraries have the same problem.
I pointed Kazu to those bugs last night (I cannot find them right now).

-- Pinski

Re: A trouble with libssp in one-tree builds

[DJ Delorie]

> We are just testing if the c compiler can compile.  Nothing more at this
> point.  I should point out other target libraries have the same problem.
> I pointed Kazu to those bugs last night (I cannot find them right now).

GCC_NO_EXECUTABLES ?

Re: A trouble with libssp in one-tree builds

[Dan Kegel]

Daniel Jacobowitz wrote:
> I think we need to finally come up with a way to build the compiler and
> libraries at different times.

Don't tease me.

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html