typeof woes in symbol renaming, or glibc x gcc

typeof woes in symbol renaming, or glibc x gcc

[Alexandre Oliva]

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

A recent change in glibc exposed a latent bug in GCC.  Glibc uses some
tricks to rename symbols, that have worked on functions for a while,
but that had never been used on data symbols, and they happened to
malfunction on platforms that defined ASM_OUTPUT_EXTERNAL (IA64, MIPS
and a few others).  It failed because, given the following code:

extern int foo;
extern __typeof(foo) foo asm("bar");
int foo = 1;

we'd call assemble_external() while processing the reference to `foo'
within typeof, where we clearly don't need to be concerned about
emitting external declarations in the assembler.  The ill effect was
that the decl for foo would be bound to the name `foo' within
assemble_external().  This was a bit too early for asm("bar") to take
effect.  When we get to the point of processing the second declaration
of foo, that would give it the name bar, the RTL already generated for
the first decl is reused, so we keep on generating foo when
referencing it, instead of using the new name.

The solution I implemented that fixed the problem was to arrange for
typeof to enter skip_evaluation mode (I was surprised to find out it
didn't) and then arrange for no RTL or assembly code to be generated
for references that occur while in skip_evaluation mode.

An earlier version of this patch, that only modified the C front-end,
passed bootstrap in IA64 (thanks, Jakub!).  Jakub also noticed that
the problem affected C++ too, and kindly wrote testcases for me
(thanks again! :-).  I've tested this patch myself on
athlon-pc-linux-gnu-x-mips-elf.

Ok to install?


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: typeof-skip-eval.patch --]
[-- Type: text/x-patch, Size: 8343 bytes --]

Index: gcc/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* c-tree.h (skip_evaluation): Move declaration...
	* c-common.h: ... here.
	* c-typeck.c (build_external_ref): Don't assemble_external nor
	mark a tree as used if skip_evaluation is set.
	* c-parse.in (typeof): New non-terminal to set skip_evaluation
	around TYPEOF.
	(typespec_nonreserved_nonattr): Use it.

Index: gcc/c-tree.h
===================================================================
RCS file: /cvs/uberbaum/gcc/c-tree.h,v
retrieving revision 1.104
diff -u -p -r1.104 c-tree.h
--- gcc/c-tree.h 10 Aug 2002 02:18:27 -0000 1.104
+++ gcc/c-tree.h 12 Aug 2002 20:57:29 -0000
@@ -311,11 +311,6 @@ extern int current_function_returns_null
 
 extern int current_function_returns_abnormally;
 
-/* Nonzero means the expression being parsed will never be evaluated.
-   This is a count, since unevaluated expressions can nest.  */
-
-extern int skip_evaluation;
-
 /* Nonzero means we are reading code that came from a system header file.  */
 
 extern int system_header_p;
Index: gcc/c-common.h
===================================================================
RCS file: /cvs/uberbaum/gcc/c-common.h,v
retrieving revision 1.152
diff -u -p -r1.152 c-common.h
--- gcc/c-common.h 12 Aug 2002 06:02:52 -0000 1.152
+++ gcc/c-common.h 12 Aug 2002 20:57:29 -0000
@@ -790,6 +790,11 @@ extern int warn_deprecated;
 
 extern int max_tinst_depth;
 
+/* Nonzero means the expression being parsed will never be evaluated.
+   This is a count, since unevaluated expressions can nest.  */
+
+extern int skip_evaluation;
+
 /* C types are partitioned into three subsets: object, function, and
    incomplete types.  */
 #define C_TYPE_OBJECT_P(type) \
Index: gcc/c-typeck.c
===================================================================
RCS file: /cvs/uberbaum/gcc/c-typeck.c,v
retrieving revision 1.202
diff -u -p -r1.202 c-typeck.c
--- gcc/c-typeck.c 10 Aug 2002 02:18:27 -0000 1.202
+++ gcc/c-typeck.c 12 Aug 2002 20:57:33 -0000
@@ -1441,7 +1441,8 @@ build_external_ref (id, fun)
   if (TREE_TYPE (ref) == error_mark_node)
     return error_mark_node;
 
-  assemble_external (ref);
+  if (!skip_evaluation)
+    assemble_external (ref);
   TREE_USED (ref) = 1;
 
   if (TREE_CODE (ref) == CONST_DECL)
Index: gcc/c-parse.in
===================================================================
RCS file: /cvs/uberbaum/gcc/c-parse.in,v
retrieving revision 1.151
diff -u -p -r1.151 c-parse.in
--- gcc/c-parse.in 10 Aug 2002 02:18:27 -0000 1.151
+++ gcc/c-parse.in 12 Aug 2002 20:57:35 -0000
@@ -562,6 +562,10 @@ alignof:
 	ALIGNOF { skip_evaluation++; }
 	;
 
+typeof:
+	TYPEOF { skip_evaluation++; }
+	;
+
 cast_expr:
 	unary_expr
 	| '(' typename ')' cast_expr  %prec UNARY
@@ -1394,10 +1398,10 @@ ifobjc
         | non_empty_protocolrefs
                 { $$ = get_object_reference ($1); }
 end ifobjc
-	| TYPEOF '(' expr ')'
-		{ $$ = TREE_TYPE ($3); }
-	| TYPEOF '(' typename ')'
-		{ $$ = groktypename ($3); }
+	| typeof '(' expr ')'
+		{ skip_evaluation--; $$ = TREE_TYPE ($3); }
+	| typeof '(' typename ')'
+		{ skip_evaluation--; $$ = groktypename ($3); }
 	;
 
 /* typespec_nonreserved_attr does not exist.  */
Index: gcc/cp/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* parse.y (sizeof, alignof, typeof): New non-terminals to
	increment skip_evaluation.  Replace terminals with them and
	decrement skip_evaluation at the end of rules using them.
	* decl2.c (mark_used): Don't assemble_external if
	skipping evaluation.

Index: gcc/cp/parse.y
===================================================================
RCS file: /cvs/uberbaum/gcc/cp/parse.y,v
retrieving revision 1.277
diff -u -p -r1.277 parse.y
--- gcc/cp/parse.y 11 Aug 2002 18:30:24 -0000 1.277
+++ gcc/cp/parse.y 12 Aug 2002 20:57:47 -0000
@@ -1277,16 +1277,20 @@ unary_expr:
 	/* Refer to the address of a label as a pointer.  */
 	| ANDAND identifier
 		{ $$ = finish_label_address_expr ($2); }
-	| SIZEOF unary_expr  %prec UNARY
-		{ $$ = finish_sizeof ($2); }
-	| SIZEOF '(' type_id ')'  %prec HYPERUNARY
+	| sizeof unary_expr  %prec UNARY
+		{ $$ = finish_sizeof ($2);
+		  skip_evaluation--; }
+	| sizeof '(' type_id ')'  %prec HYPERUNARY
 		{ $$ = finish_sizeof (groktypename ($3.t));
-		  check_for_new_type ("sizeof", $3); }
-	| ALIGNOF unary_expr  %prec UNARY
-		{ $$ = finish_alignof ($2); }
-	| ALIGNOF '(' type_id ')'  %prec HYPERUNARY
+		  check_for_new_type ("sizeof", $3);
+		  skip_evaluation--; }
+	| alignof unary_expr  %prec UNARY
+		{ $$ = finish_alignof ($2);
+		  skip_evaluation--; }
+	| alignof '(' type_id ')'  %prec HYPERUNARY
 		{ $$ = finish_alignof (groktypename ($3.t));
-		  check_for_new_type ("alignof", $3); }
+		  check_for_new_type ("alignof", $3);
+		  skip_evaluation--; }
 
 	/* The %prec EMPTY's here are required by the = init initializer
 	   syntax extension; see below.  */
@@ -2004,6 +2008,18 @@ reserved_typespecquals:
 		{ $$ = tree_cons ($1, NULL_TREE, NULL_TREE); }
 	;
 
+sizeof:
+	SIZEOF { skip_evaluation++; }
+	;
+
+alignof:
+	ALIGNOF { skip_evaluation++; }
+	;
+
+typeof:
+	TYPEOF { skip_evaluation++; }
+	;
+
 /* A typespec (but not a type qualifier).
    Once we have seen one of these in a declaration,
    if a typedef name appears then it is being redeclared.  */
@@ -2015,12 +2031,14 @@ typespec:
 		{ $$.t = $1; $$.new_type_flag = 0; $$.lookups = NULL_TREE; }
 	| complete_type_name
 		{ $$.t = $1; $$.new_type_flag = 0; $$.lookups = NULL_TREE; }
-	| TYPEOF '(' expr ')'
+	| typeof '(' expr ')'
 		{ $$.t = finish_typeof ($3);
-		  $$.new_type_flag = 0; $$.lookups = NULL_TREE; }
-	| TYPEOF '(' type_id ')'
+		  $$.new_type_flag = 0; $$.lookups = NULL_TREE;
+		  skip_evaluation--; }
+	| typeof '(' type_id ')'
 		{ $$.t = groktypename ($3.t);
-		  $$.new_type_flag = 0; $$.lookups = NULL_TREE; }
+		  $$.new_type_flag = 0; $$.lookups = NULL_TREE;
+		  skip_evaluation--; }
 	| SIGOF '(' expr ')'
 		{ tree type = TREE_TYPE ($3);
 
Index: gcc/cp/decl2.c
===================================================================
RCS file: /cvs/uberbaum/gcc/cp/decl2.c,v
retrieving revision 1.559
diff -u -p -r1.559 decl2.c
--- gcc/cp/decl2.c 11 Aug 2002 18:30:24 -0000 1.559
+++ gcc/cp/decl2.c 12 Aug 2002 20:57:51 -0000
@@ -4717,7 +4717,8 @@ mark_used (decl)
   TREE_USED (decl) = 1;
   if (processing_template_decl)
     return;
-  assemble_external (decl);
+  if (!skip_evaluation)
+    assemble_external (decl);
 
   /* Is it a synthesized method that needs to be synthesized?  */
   if (TREE_CODE (decl) == FUNCTION_DECL
Index: gcc/testsuite/ChangeLog
from  Jakub Jelinek  <jakub@redhat.com>

	* gcc.dg/typeof-1.c: New test.
	* g++.dg/ext/typeof2.C: New test.

Index: gcc/testsuite/gcc.dg/typeof-1.c
===================================================================
RCS file: gcc/testsuite/gcc.dg/typeof-1.c
diff -N gcc/testsuite/gcc.dg/typeof-1.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gcc/testsuite/gcc.dg/typeof-1.c 12 Aug 2002 20:57:56 -0000
@@ -0,0 +1,27 @@
+/* Test typeof with __asm redirection. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+extern int foo1;
+extern int foo1 __asm ("bar1");
+int foo1 = 1;
+
+extern int foo2 (int);
+extern int foo2 (int) __asm ("bar2");
+int foo2 (int x)
+{
+  return x;
+}
+
+extern int foo3;
+extern __typeof (foo3) foo3 __asm ("bar3");
+int foo3 = 1;
+
+extern int foo4 (int);
+extern __typeof (foo4) foo4 __asm ("bar4");
+int foo4 (int x)
+{
+  return x;
+}
+
+// { dg-final { scan-assembler-not "foo" } }
Index: gcc/testsuite/g++.dg/ext/typeof2.C
===================================================================
RCS file: gcc/testsuite/g++.dg/ext/typeof2.C
diff -N gcc/testsuite/g++.dg/ext/typeof2.C
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gcc/testsuite/g++.dg/ext/typeof2.C 12 Aug 2002 20:57:56 -0000
@@ -0,0 +1,29 @@
+// Test typeof with __asm redirection
+// { dg-do compile }
+// { dg-options "-O2" }
+
+extern "C" {
+  extern int foo1;
+  extern int foo1 __asm ("bar1");
+  int foo1 = 1;
+
+  extern int foo2 (int);
+  extern int foo2 (int) __asm ("bar2");
+  int foo2 (int x)
+  {
+    return x;
+  }
+
+  extern int foo3;
+  extern __typeof (foo3) foo3 __asm ("bar3");
+  int foo3 = 1;
+
+  extern int foo4 (int);
+  extern __typeof (foo4) foo4 __asm ("bar4");
+  int foo4 (int x)
+  {
+    return x;
+  }
+}
+
+// { dg-final { scan-assembler-not "foo" } }

[-- Attachment #3: Type: text/plain, Size: 289 bytes --]


-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: typeof woes in symbol renaming, or glibc x gcc

[Andreas Jaeger]

Alexandre Oliva <aoliva@redhat.com> writes:

> A recent change in glibc exposed a latent bug in GCC.  Glibc uses some
> tricks to rename symbols, that have worked on functions for a while,
> but that had never been used on data symbols, and they happened to
> malfunction on platforms that defined ASM_OUTPUT_EXTERNAL (IA64, MIPS
> and a few others).  It failed because, given the following code:
>
> extern int foo;
> extern __typeof(foo) foo asm("bar");
> int foo = 1;
>
> we'd call assemble_external() while processing the reference to `foo'
> within typeof, where we clearly don't need to be concerned about
> emitting external declarations in the assembler.  The ill effect was
> that the decl for foo would be bound to the name `foo' within
> assemble_external().  This was a bit too early for asm("bar") to take
> effect.  When we get to the point of processing the second declaration
> of foo, that would give it the name bar, the RTL already generated for
> the first decl is reused, so we keep on generating foo when
> referencing it, instead of using the new name.
>
> The solution I implemented that fixed the problem was to arrange for
> typeof to enter skip_evaluation mode (I was surprised to find out it
> didn't) and then arrange for no RTL or assembly code to be generated
> for references that occur while in skip_evaluation mode.
>
> An earlier version of this patch, that only modified the C front-end,
> passed bootstrap in IA64 (thanks, Jakub!).  Jakub also noticed that
> the problem affected C++ too, and kindly wrote testcases for me
> (thanks again! :-).  I've tested this patch myself on
> athlon-pc-linux-gnu-x-mips-elf.
>
> Ok to install?

Is this something for 3.2.1?  Or does it only fail on mainline?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[PATCH] Another typeof+asm test (was Re: typeof woes in symbol renaming, or glibc x gcc)

[Jakub Jelinek]

On Wed, Aug 14, 2002 at 06:42:09AM +0200, Andreas Jaeger wrote:
> > The solution I implemented that fixed the problem was to arrange for
> > typeof to enter skip_evaluation mode (I was surprised to find out it
> > didn't) and then arrange for no RTL or assembly code to be generated
> > for references that occur while in skip_evaluation mode.
> >
> > An earlier version of this patch, that only modified the C front-end,
> > passed bootstrap in IA64 (thanks, Jakub!).  Jakub also noticed that
> > the problem affected C++ too, and kindly wrote testcases for me
> > (thanks again! :-).  I've tested this patch myself on
> > athlon-pc-linux-gnu-x-mips-elf.
> >
> > Ok to install?
> 
> Is this something for 3.2.1?  Or does it only fail on mainline?

It fails in 3.2.x and failed in various ways in the past compilers too,
that's why glibc has checks for this in its configury and only optimizes
if all works as expected.
IMHO it should be something for 3.2.1 too.
I think backport of __attribute__((visibility())) stuff would be
useful too.

Below is another testcase to test typeof+asm behaviour glibc relies on.
Ok to commit?

2002-08-14  Jakub Jelinek  <jakub@redhat.com>

	* gcc.dg/typeof-2.c: New test.

--- gcc/testsuite/gcc.dg/typeof-2.c.jj	2002-08-08 20:42:33.000000000 +0200
+++ gcc/testsuite/gcc.dg/typeof-2.c	2002-08-08 20:47:53.000000000 +0200
@@ -0,0 +1,29 @@
+/* Test typeof with __asm redirection. */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+extern int foo1 (int x) __asm ("baz1");
+int bar1 (int x) { return x; }
+extern __typeof (bar1) foo1 __attribute ((weak, alias ("bar1")));
+
+extern int foo2 (int x) __attribute__ ((const));
+extern __typeof (foo2) foo2 __asm ("baz2");
+int bar2 (int x)
+{
+  return foo2 (x) + foo2 (x) + foo2 (x) + foo2 (x) + foo2 (x) + foo2 (x);
+}
+
+extern int foo3 (int x);
+extern __typeof (foo3) foo3 __asm ("baz3");
+int bar3 (int x)
+{
+  return foo3 (x) + foo3 (x) + foo3 (x) + foo3 (x) + foo3 (x) + foo3 (x);
+}
+
+// { dg-final { scan-assembler-not "foo1" } }
+// { dg-final { scan-assembler "baz1" } }
+// { dg-final { scan-assembler-not "foo2" } }
+// { dg-final { scan-assembler "baz2" } }
+// { dg-final { scan-assembler-not "baz2.*baz2.*baz2.*baz2.*baz2.*baz2" } }
+// { dg-final { scan-assembler-not "foo3" } }
+// { dg-final { scan-assembler "baz3.*baz3.*baz3.*baz3.*baz3.*baz3" } }

	Jakub

Re: typeof woes in symbol renaming, or glibc x gcc

[Mark Mitchell]

--On Wednesday, August 14, 2002 01:28:52 AM -0300 Alexandre Oliva 
<aoliva@redhat.com> wrote:

> A recent change in glibc exposed a latent bug in GCC.  Glibc uses some
> tricks to rename symbols, that have worked on functions for a while,
> but that had never been used on data symbols, and they happened to
> malfunction on platforms that defined ASM_OUTPUT_EXTERNAL (IA64, MIPS
> and a few others).  It failed because, given the following code:

OK, thanks.

I will note that this was the one of the easier patches to approve in
a long time.  Excellent description of the problem, as well as a nice
clean fix.

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

Re: [PATCH] Another typeof+asm test (was Re: typeof woes in symbol renaming, or glibc x gcc)

[Richard Henderson]

On Wed, Aug 14, 2002 at 01:04:03AM -0400, Jakub Jelinek wrote:
> I think backport of __attribute__((visibility())) stuff would be
> useful too.

Ask Mark for branch permission.

> 	* gcc.dg/typeof-2.c: New test.

Ok.


r~

Re: typeof woes in symbol renaming, or glibc x gcc

[Alexandre Oliva]

On Aug 14, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

> --On Wednesday, August 14, 2002 01:28:52 AM -0300 Alexandre Oliva
> <aoliva@redhat.com> wrote:

>> A recent change in glibc exposed a latent bug in GCC.  Glibc uses some
>> tricks to rename symbols, that have worked on functions for a while,
>> but that had never been used on data symbols, and they happened to
>> malfunction on platforms that defined ASM_OUTPUT_EXTERNAL (IA64, MIPS
>> and a few others).  It failed because, given the following code:

> OK, thanks.

For the 3.2 branch too?

> I will note that this was the one of the easier patches to approve in
> a long time.  Excellent description of the problem, as well as a nice
> clean fix.

Thanks :-)  After such a long time away from this forum, I'm happy I
came back doing something right :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: typeof woes in symbol renaming, or glibc x gcc

[Alexandre Oliva]

On Aug 15, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Aug 14, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
>> --On Wednesday, August 14, 2002 01:28:52 AM -0300 Alexandre Oliva
>> <aoliva@redhat.com> wrote:

>>> A recent change in glibc exposed a latent bug in GCC.  Glibc uses some
>>> tricks to rename symbols, that have worked on functions for a while,
>>> but that had never been used on data symbols, and they happened to
>>> malfunction on platforms that defined ASM_OUTPUT_EXTERNAL (IA64, MIPS
>>> and a few others).  It failed because, given the following code:

>> OK, thanks.

> For the 3.2 branch too?

Ping.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: typeof woes in symbol renaming, or glibc x gcc

[Alexandre Oliva]

On Aug 20, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:

> On Aug 15, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Aug 14, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
>>> --On Wednesday, August 14, 2002 01:28:52 AM -0300 Alexandre Oliva
>>> <aoliva@redhat.com> wrote:

>>>> A recent change in glibc exposed a latent bug in GCC.  Glibc uses some
>>>> tricks to rename symbols, that have worked on functions for a while,
>>>> but that had never been used on data symbols, and they happened to
>>>> malfunction on platforms that defined ASM_OUTPUT_EXTERNAL (IA64, MIPS
>>>> and a few others).  It failed because, given the following code:

>>> OK, thanks.

>> For the 3.2 branch too?

> Ping.

Ping.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: typeof woes in symbol renaming, or glibc x gcc

[Mark Mitchell]

--On Tuesday, August 27, 2002 03:40:47 PM -0300 Alexandre Oliva 
<aoliva@redhat.com> wrote:

> On Aug 20, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:
>
>> On Aug 15, 2002, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> On Aug 14, 2002, Mark Mitchell <mark@codesourcery.com> wrote:
>>>> --On Wednesday, August 14, 2002 01:28:52 AM -0300 Alexandre Oliva
>>>> <aoliva@redhat.com> wrote:
>
>>>>> A recent change in glibc exposed a latent bug in GCC.  Glibc uses some
>>>>> tricks to rename symbols, that have worked on functions for a while,
>>>>> but that had never been used on data symbols, and they happened to
>>>>> malfunction on platforms that defined ASM_OUTPUT_EXTERNAL (IA64, MIPS
>>>>> and a few others).  It failed because, given the following code:
>
>>>> OK, thanks.
>
>>> For the 3.2 branch too?

If it's a regression, yes.  Otherwise, no.

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

Re: typeof woes in symbol renaming, or glibc x gcc

[Alexandre Oliva]

On Aug 27, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

>>>> For the 3.2 branch too?

> If it's a regression, yes.  Otherwise, no.

I don't think it is a regression, no.  Unless `I was able to build an
earlier version of glibc with the symbol versioning feature enabled,
but this feature is not enabled in CVS glibc' count as a regression.

Does the fact that the upcoming glibc 2.3 won't be built properly
without this patch in GCC, so every GNU/Linux vendor that adopts GCC
3.2 and glibc 2.3 will probably install this patch themselves, help
get the patch accepted for 3.2.1?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: typeof woes in symbol renaming, or glibc x gcc

[Mark Mitchell]

> Does the fact that the upcoming glibc 2.3 won't be built properly
> without this patch in GCC, so every GNU/Linux vendor that adopts GCC
> 3.2 and glibc 2.3 will probably install this patch themselves, help
> get the patch accepted for 3.2.1?

Well, OK.

But the GNU/Linux vendors ought to work to avoid this situation; forcing
potentially destabilizing changes on the overall GCC community isn't
the right thing to do.

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

Re: typeof woes in symbol renaming, or glibc x gcc

[Daniel Jacobowitz]

On Wed, Aug 28, 2002 at 04:34:11PM -0700, Mark Mitchell wrote:
> >Does the fact that the upcoming glibc 2.3 won't be built properly
> >without this patch in GCC, so every GNU/Linux vendor that adopts GCC
> >3.2 and glibc 2.3 will probably install this patch themselves, help
> >get the patch accepted for 3.2.1?
> 
> Well, OK.
> 
> But the GNU/Linux vendors ought to work to avoid this situation; forcing
> potentially destabilizing changes on the overall GCC community isn't
> the right thing to do.

GNU/Linux vendors haven't got a choice.  Glibc and GCC tend to be
loosely tied together in version requirements.  By nature of their
schedules, glibc releases tend to be fresher than GCC releases; for
instance, 2.3 has TLS support which I noticed Red Hat has ported the
GCC 3.3 patches to 3.2 for.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: typeof woes in symbol renaming, or glibc x gcc

[Mark Mitchell]

--On Wednesday, August 28, 2002 10:54:44 PM -0400 Daniel Jacobowitz 
<drow@mvista.com> wrote:

> On Wed, Aug 28, 2002 at 04:34:11PM -0700, Mark Mitchell wrote:
>> > Does the fact that the upcoming glibc 2.3 won't be built properly
>> > without this patch in GCC, so every GNU/Linux vendor that adopts GCC
>> > 3.2 and glibc 2.3 will probably install this patch themselves, help
>> > get the patch accepted for 3.2.1?
>>
>> Well, OK.
>>
>> But the GNU/Linux vendors ought to work to avoid this situation; forcing
>> potentially destabilizing changes on the overall GCC community isn't
>> the right thing to do.
>
> GNU/Linux vendors haven't got a choice.

Sure they do.

I understand how new stuff in GCC gets used in glibc, and how then
*if* you commit to the latest version of glibc you need changes to
GCC that aren't there in a released version.

Note the *if*.  There's no rule that says that you have to ship glibc
2.3 just because it is out.

I'm sure there are very good reasons for wanting the lastest glibc, but
I would be happier if the distributors had picked the glibc version
they wanted, figured out what stuff needed to be in GCC to accomplish
that, and had gotten that into a major version of GCC, and then had used
that GCC.

The problem is that pulling stuff into minor releases of GCC because
its needed in glibc puts us in a difficult position.  If those things
are at all risky-looking, we risk destabilizing the compiler for all
users, including those who aren't GNU/Linux users.

Alexandre's patch was very clean, and very well explained, and that
helped me decide that it wasn't likely to mess anything up.  For those
kinds of patches, there isn't much of an issue.

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

Re: typeof woes in symbol renaming, or glibc x gcc

[Alexandre Oliva]

On Aug 29, 2002, Mark Mitchell <mark@codesourcery.com> wrote:

>> GNU/Linux vendors haven't got a choice.

> Sure they do.

> I understand how new stuff in GCC gets used in glibc, and how then
> *if* you commit to the latest version of glibc you need changes to
> GCC that aren't there in a released version.

> Note the *if*.  There's no rule that says that you have to ship glibc
> 2.3 just because it is out.

It's not that simple.  We use the same compiler to build the entire
distro.  I doubt any single version of GCC would be able to build all
packages on all architectures we support.  Even if the GCC release
schedule happened to coincide with ours (which would surely be fun for
conspiracy theorists :-), or perhaps with every other GNU/Linux
vendor's, we'd still be in a difficult position because such schedules
aren't public and, even if they were, some distros include more
packages than others, or at least different versions of the same
packages, or target fewer architectures.  So, those who happened to
use only packages that already build fine could press the release
manager to put the release out, so that they could release their
product based on it.

I.e., it would be a nightmare you probably wouldn't want to be in :-)
Better leave each GNU/Linux vendor support the compiler the compiler
they ship.

> I'm sure there are very good reasons for wanting the lastest glibc, but
> I would be happier if the distributors had picked the glibc version
> they wanted, figured out what stuff needed to be in GCC to accomplish
> that, and had gotten that into a major version of GCC, and then had used
> that GCC.

This is exactly what we did.  Except that the changes in glibc that
exposed bugs in GCC 3.2 in some platforms hadn't been made yet, and
now that GCC 3.2 is already out, it's impossible to go back and fix
it, and glibc developers are adamant that they won't go out of their
way because of compiler bugs.  If the fix for a bug in glibc happens
to break other software, that's too bad, but the bug has to be fixed.
To wit, check out the current CVS tree of glibc, and try to build GCC
3.2 (or even GCC mainline) with it.  libstdc++-v3 won't build because
of a change in ctype.h required by changes in the implementation of
locale.  This change went in in the last 24 hours.  How could we have
fixed GCC 3.2 to cope with it?  Or are we saying we shouldn't have
decided we wanted to track the glibc 2.3 code base for our next
release, and instead have shorter ABI-breaking cycles, since the next
release is based on GCC 3.2, and we'd need another one whenever we
switched to glibc 2.3?  Historically, we've changed compiler and glibc
major releases at the same time.

> The problem is that pulling stuff into minor releases of GCC because
> its needed in glibc puts us in a difficult position.  If those things
> are at all risky-looking, we risk destabilizing the compiler for all
> users, including those who aren't GNU/Linux users.

I agree and understand.  You, as the Release Manager of GCC for the
Free Software foundation, is not required to accept such changes.
You're also free to get in touch with the maintainers of the GNU C
library to ask them to avoid making changes that would expose problems
in GCC and force vendors of systems based on the GNU C library to
either (i) integrate patches despite the GCC RM's ruling, (ii) revert
a patch in glibc despite its maintainers' ruling, (iii) wait until a
new version of GCC goes out that fixes the problem (and probably
introduces others :-) or (iv) stick to an earlier version of glibc.

Since (iii) is too risky and (iv) is undesirable, we often found
ourselves between (i) and (ii).  Since fixing a bug in the compiler is
often better than turning our copy of the C library incompatible with
everybody else's, it's not too hard to realize we often end up picking
(i).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer