public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [C++ PATCH] Fix a regression introduced by my PR34094 fix (PR c++/34238)
@ 2007-11-27  4:17 Jakub Jelinek
  2007-12-05 15:03 ` [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR c++/34238, c++/34340) Jakub Jelinek
  0 siblings, 1 reply; 8+ messages in thread
From: Jakub Jelinek @ 2007-11-27  4:17 UTC (permalink / raw)
  To: Jason Merrill, Mark Mitchell; +Cc: gcc-patches

Hi!

As shown by the attached testcase (which is probably valid, as
A<>::a is never used and so it shouldn't be necessary to define
it), the DECL_INITIAL (decl) == NULL check doesn't work in cases
where it is actually never needed, only instantiated
(in that case tsubst_decl clears DECL_INITIAL:
        /* We do NOT check for matching decls pushed separately at this
           point, as they may not represent instantiations of this
           template, and in any case are considered separate under the
           discrete model.  */
        r = copy_decl (t);
        DECL_USE_TEMPLATE (r) = 0;
        TREE_TYPE (r) = type;
        /* Clear out the mangled name and RTL for the instantiation.  */
        SET_DECL_ASSEMBLER_NAME (r, NULL_TREE);
        SET_DECL_RTL (r, NULL_RTX);
        DECL_INITIAL (r) = NULL_TREE;
        DECL_CONTEXT (r) = ctx;
).  The following patch fixes that.  For the const static data members 
with initializers in the class definition we won't issue any diagnostics,
but IMHO that's far less severe than making up the vars with default
initializer when there is none.  I've also tried (attached patch)
instead delay this diagnostics after the vars have been output, so we
know for sure if it was emitted or not.  That also fixes this anon9.C
and anon10.C gives diagnostics while it is without any diagnostics ATM,
but anon6.C breaks - there is the A<int>::c var actually emitted into
assembly, even when nobody really needs it :( (with or without the patch),
so with that alternate patch which checks TREE_ASM_WRITTEN we error on
anon6.C.

Is the first patch ok for trunk?  Bootstrapped/regtested on x86_64-linux.

2007-11-26  Jakub Jelinek  <jakub@redhat.com>

	PR c++/34238
	* decl2.c (cp_write_global_declarations): Test
	!DECL_INITIALIZED_IN_CLASS_P instead of checking NULL
	DECL_INITIAL.

	* g++.dg/ext/visibility/anon9.C: New test.

--- gcc/cp/decl2.c.jj	2007-11-22 15:03:54.000000000 +0100
+++ gcc/cp/decl2.c	2007-11-26 21:04:38.000000000 +0100
@@ -3375,7 +3375,7 @@ cp_write_global_declarations (void)
 		 namespace { struct A { static const int i = 4; } };
 		 decl_needed_p won't reliably detect whether it was
 		 really needed.  */
-	      if (DECL_IN_AGGR_P (decl) && DECL_INITIAL (decl) == NULL_TREE)
+	      if (DECL_IN_AGGR_P (decl) && !DECL_INITIALIZED_IN_CLASS_P (decl))
 		error ("%Jstatic data member %qD used, but not defined",
 		       decl, decl);
 	      DECL_EXTERNAL (decl) = 0;
--- gcc/testsuite/g++.dg/ext/visibility/anon9.C.jj	2007-11-26 21:37:34.000000000 +0100
+++ gcc/testsuite/g++.dg/ext/visibility/anon9.C	2007-11-26 21:38:01.000000000 +0100
@@ -0,0 +1,11 @@
+// PR c++/34238
+// { dg-do compile }
+
+namespace
+{
+  template <typename T = int> struct A
+  {
+    static const bool a = true;
+  };
+}
+struct A<> a;

	Jakub

^ permalink raw reply	[flat|nested] 8+ messages in thread

* [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR c++/34238, c++/34340)
  2007-11-27  4:17 [C++ PATCH] Fix a regression introduced by my PR34094 fix (PR c++/34238) Jakub Jelinek
@ 2007-12-05 15:03 ` Jakub Jelinek
  2007-12-07  4:31   ` Mark Mitchell
  0 siblings, 1 reply; 8+ messages in thread
From: Jakub Jelinek @ 2007-12-05 15:03 UTC (permalink / raw)
  To: Jason Merrill, Mark Mitchell; +Cc: gcc-patches

Hi!

Over time more problems with PR34094 fix have been reported, they are
summarized in the testcases below.
The following patch (which obsoletes my earlier 34238 patch) fixes all of
this, but letting cgraph_optimize actually emit all the vars into assembly
and only checking afterwards if we emitted something we shouldn't, which
seems to be much more reliable.
We still need to special case static data members initialized in the class,
because at least ATM sometimes such decls are emitted into assembly even if
they e.g. are just used through value (and thus not needed), while their
address wasn't taken etc., and we need to use for that
DECL_INITIALIZED_IN_CLASS_P test rather than check for non-NULL
DECL_INITIAL, because in templates even when initialized in class
DECL_INITIAL is often NULL.

Regtested on x86_64-linux, ok for trunk?

2007-12-05  Jakub Jelinek  <jakub@redhat.com>

	PR c++/34238
	PR c++/34340
	* decl2.c (cp_write_global_declarations): Move diagnostics about
	static data member used, but not defined, after cgraph_optimize,
	error only for decls that have been written and weren't
	DECL_INITIALIZED_IN_CLASS_P.

	* g++.dg/ext/visibility/anon9.C: New test.
	* g++.dg/ext/visibility/anon10.C: New test.
	* g++.dg/ext/visibility/repo7.C: New test.

--- gcc/cp/decl2.c.jj	2007-12-04 20:33:17.000000000 +0100
+++ gcc/cp/decl2.c	2007-12-05 13:37:34.000000000 +0100
@@ -3365,21 +3365,7 @@ cp_write_global_declarations (void)
 	  /* If this static data member is needed, provide it to the
 	     back end.  */
 	  if (DECL_NOT_REALLY_EXTERN (decl) && decl_needed_p (decl))
-	    {
-	      /* Error on
-		 namespace { struct A { static int i; }; }
-		 int foo () { return A::i; }
-		 without A::i definition (which can't be defined in
-		 a different CU because of the anonymous namespace).
-		 Don't do this if DECL_INITIAL is set, because for
-		 namespace { struct A { static const int i = 4; } };
-		 decl_needed_p won't reliably detect whether it was
-		 really needed.  */
-	      if (DECL_IN_AGGR_P (decl) && DECL_INITIAL (decl) == NULL_TREE)
-		error ("%Jstatic data member %qD used, but not defined",
-		       decl, decl);
-	      DECL_EXTERNAL (decl) = 0;
-	    }
+	    DECL_EXTERNAL (decl) = 0;
 	}
       if (VEC_length (tree, pending_statics) != 0
 	  && wrapup_global_declarations (VEC_address (tree, pending_statics),
@@ -3450,6 +3436,21 @@ cp_write_global_declarations (void)
 				 VEC_length (tree, pending_statics));
       emit_debug_global_declarations (VEC_address (tree, pending_statics),
 				      VEC_length (tree, pending_statics));
+      /* Error on
+	 namespace { struct A { static int i; }; }
+	 int foo () { return A::i; }
+	 without A::i definition (which can't be defined in
+	 a different CU because of the anonymous namespace).
+	 Don't do this if DECL_INITIALIZED_IN_CLASS_P is set, because for
+	 namespace { struct A { static const int i = 4; } };
+	 we won't reliably detect whether it was really needed
+	 and the definition couldn't provide different value than
+	 the initialized in class anyway.  */
+      for (i = 0; VEC_iterate (tree, pending_statics, i, decl); ++i)
+	if (DECL_IN_AGGR_P (decl)
+	    && TREE_ASM_WRITTEN (decl)
+	    && !DECL_INITIALIZED_IN_CLASS_P (decl))
+	  error ("%Jstatic data member %qD used, but not defined", decl, decl);
     }
 
   /* Generate hidden aliases for Java.  */
--- gcc/testsuite/g++.dg/ext/visibility/anon9.C.jj	2007-12-04 20:44:19.000000000 +0100
+++ gcc/testsuite/g++.dg/ext/visibility/anon9.C	2007-12-04 20:44:19.000000000 +0100
@@ -0,0 +1,11 @@
+// PR c++/34238
+// { dg-do compile }
+
+namespace
+{
+  template <typename T = int> struct A
+  {
+    static const bool a = true;
+  };
+}
+struct A<> a;
--- gcc/testsuite/g++.dg/ext/visibility/anon10.C.jj	2007-12-05 15:07:46.000000000 +0100
+++ gcc/testsuite/g++.dg/ext/visibility/anon10.C	2007-12-05 15:05:16.000000000 +0100
@@ -0,0 +1,44 @@
+// http://bugzilla.redhat.com/411871
+// { dg-do compile }
+
+extern "C" int printf (const char *, ...);
+
+struct E
+{
+  template <typename T> E (const volatile T&);
+  template <typename T> E (T&);
+  char x[64];
+};
+
+template<typename T> struct D
+{
+  static E foo (E, ...);
+  static int foo (T, int);
+};
+
+template<typename T, typename U> struct C
+{
+  static T ca;
+  static const int value = sizeof (D<U>::foo (ca, 0)) == sizeof (int);
+};
+
+struct A
+{
+  int a;
+};
+
+namespace
+{
+  struct B
+  {
+    int a;
+  };
+}
+
+int bar (void)
+{
+  C<A, int> a;
+  C<B, int> b;
+
+  return a.value + b.value;
+}
--- gcc/testsuite/g++.dg/template/repo7.C.jj	2007-12-05 13:46:47.000000000 +0100
+++ gcc/testsuite/g++.dg/template/repo7.C	2007-12-05 13:46:35.000000000 +0100
@@ -0,0 +1,29 @@
+// PR c++/34340
+// { dg-options "-frepo" }
+// { dg-final { cleanup-repo-files } }
+// { dg-require-host-local "" }
+
+struct A
+{
+  int a;
+};
+
+struct B
+{
+  static const A b;
+};
+
+template <typename T> struct D : public T
+{
+  static const A b;
+};
+
+const A B::b = { 1 };
+
+template<typename T> const A D<T>::b = { 2 };
+template class D<B>;
+
+int
+main ()
+{
+}

	Jakub

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR  c++/34238, c++/34340)
  2007-12-05 15:03 ` [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR c++/34238, c++/34340) Jakub Jelinek
@ 2007-12-07  4:31   ` Mark Mitchell
  2007-12-07  7:53     ` Jakub Jelinek
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Mitchell @ 2007-12-07  4:31 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches

Jakub Jelinek wrote:

> The following patch (which obsoletes my earlier 34238 patch) fixes all of
> this, but letting cgraph_optimize actually emit all the vars into assembly
> and only checking afterwards if we emitted something we shouldn't, which
> seems to be much more reliable.

The diagnostic is not about what the compiler happens to end up spitting
out; it's about the user's program.  If you do:

  namespace { struct A { static int i; }; }
  static int foo() { return A::i; }

the program is still erroneous, even though the compiler may likely
optimize away foo, and the reference to A::i.  So, I don't think we
should be doing this check after cgraph_optimize.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR  c++/34238, c++/34340)
  2007-12-07  4:31   ` Mark Mitchell
@ 2007-12-07  7:53     ` Jakub Jelinek
  2007-12-07 20:52       ` Mark Mitchell
  0 siblings, 1 reply; 8+ messages in thread
From: Jakub Jelinek @ 2007-12-07  7:53 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches

On Thu, Dec 06, 2007 at 08:31:17PM -0800, Mark Mitchell wrote:
> Jakub Jelinek wrote:
> 
> > The following patch (which obsoletes my earlier 34238 patch) fixes all of
> > this, but letting cgraph_optimize actually emit all the vars into assembly
> > and only checking afterwards if we emitted something we shouldn't, which
> > seems to be much more reliable.
> 
> The diagnostic is not about what the compiler happens to end up spitting
> out; it's about the user's program.  If you do:
> 
>   namespace { struct A { static int i; }; }
>   static int foo() { return A::i; }
> 
> the program is still erroneous, even though the compiler may likely
> optimize away foo, and the reference to A::i.

That's true, but the standard explicitly says the diagnostic is not
required.  With
struct A { static int i; }; static int foo() { return A::i; } int main () {}
as whole program we wouldn't diagnose this either.  
To me it is more important that we don't error on valid programs (especially
a lot of boost using code is broken), and when all references are optimized
out, no real harm is done, compiler doesn't make up something unexpected.
When compiler puts it into bss, it can e.g. do so even for objects that need
constructing, without running any constructors on it etc.  That's something
that should be warned about.  If we have some bit which we can really rely
on to be set reliably for these purposes, then the warning can be precise,
but TREE_USED is unfortunately not it.

BTW, is the boost testcase valid?
template<typename T, typename U> struct C
{
  static T ca;
  static const int value = sizeof (D<U>::foo (ca, 0)) == sizeof (int);
};
is instantiated with T in anon namespace (so ca is also limited to current
CU), but it is (intentionally) never defined and only used in sizeof
expression.  [class.static.data]/5 says
"There shall be exactly one definition of a static data member that is used in a
program"
but it is not clear (at least to me) what exactly counts as use.
Boost certainly wouldn't like to pollute bss of programs with many
(sometimes big) variables that nobody ever uses.

I'm afraid I don't know the FE enough to further improve this warning
without breaking valid programs, so the other possibility for me is just to
back out the original patch and leave this can of worms to you/Jason.
Though, waiting for that in a state which at least errors out when real
harm is done rather than being silent even for those cases is IMHO
preferrable.

	Jakub

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR   c++/34238, c++/34340)
  2007-12-07  7:53     ` Jakub Jelinek
@ 2007-12-07 20:52       ` Mark Mitchell
  2007-12-10 13:19         ` Jakub Jelinek
  0 siblings, 1 reply; 8+ messages in thread
From: Mark Mitchell @ 2007-12-07 20:52 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches

Jakub Jelinek wrote:

>>   namespace { struct A { static int i; }; }
>>   static int foo() { return A::i; }
>>
>> the program is still erroneous, even though the compiler may likely
>> optimize away foo, and the reference to A::i.
> 
> That's true, but the standard explicitly says the diagnostic is not
> required.

It does?  Where?  (I'm not disagreeing, I'm just surprised, and I
couldn't find a pointer.)

> To me it is more important that we don't error on valid programs (especially
> a lot of boost using code is broken), and when all references are optimized
> out, no real harm is done, compiler doesn't make up something unexpected.

We don't want to issue errors about valid programs -- but we do want to
issue diagnostics about invalid programs.  Those can be warnings,
pedwarns, etc.; they don't necessarily have to stop compilation.

> that should be warned about.  If we have some bit which we can really rely
> on to be set reliably for these purposes, then the warning can be precise,
> but TREE_USED is unfortunately not it.

TREE_USED should be accurate.  It should tell us whether or not a thing
was used by the input.  If TREE_USED is not set when it should be, or
set when it shouldn't be, we have a problem.

> template<typename T, typename U> struct C
> {
>   static T ca;
>   static const int value = sizeof (D<U>::foo (ca, 0)) == sizeof (int);
> };

I don't think the standard is not entirely clear.  It says this code is
not evaluated, but I don't see anything that says that this means that
"ca" is not used.  Of course, might well not require that, independent
of what the standard says; I agree that QoI suggests not issuing an
error in this case.

> I'm afraid I don't know the FE enough to further improve this warning
> without breaking valid programs, so the other possibility for me is just to
> back out the original patch and leave this can of worms to you/Jason.

All right; let's revert your original patch, then.  AIUI, that patch
fixed an accepts-invalid problem; that's better than rejects-valid problems.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR c++/34238, c++/34340)
  2007-12-07 20:52       ` Mark Mitchell
@ 2007-12-10 13:19         ` Jakub Jelinek
  2007-12-10 20:51           ` Mark Mitchell
  2007-12-17 17:19           ` Jason Merrill
  0 siblings, 2 replies; 8+ messages in thread
From: Jakub Jelinek @ 2007-12-10 13:19 UTC (permalink / raw)
  To: Mark Mitchell; +Cc: Jason Merrill, gcc-patches

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

On Fri, Dec 07, 2007 at 12:52:31PM -0800, Mark Mitchell wrote:
> Jakub Jelinek wrote:
> 
> >>   namespace { struct A { static int i; }; }
> >>   static int foo() { return A::i; }
> >>
> >> the program is still erroneous, even though the compiler may likely
> >> optimize away foo, and the reference to A::i.
> > 
> > That's true, but the standard explicitly says the diagnostic is not
> > required.
> 
> It does?  Where?  (I'm not disagreeing, I'm just surprised, and I
> couldn't find a pointer.)

[class.static.data]/5:
"There shall be exactly one definition of a static data member that is used in a program; no diagnostic is required; see 3.2."

The patch I posted last Wednesday diagnosed the errors basically for the
same stuff that ld would diagnose it, if anon namespace was not involved.
When all uses are optimized out, etc., ld will not error nor warn either.

> > that should be warned about.  If we have some bit which we can really rely
> > on to be set reliably for these purposes, then the warning can be precise,
> > but TREE_USED is unfortunately not it.
> 
> TREE_USED should be accurate.  It should tell us whether or not a thing
> was used by the input.  If TREE_USED is not set when it should be, or
> set when it shouldn't be, we have a problem.

But it is set e.g. when seen in sizeof as shown on that boost snippet.

> > I'm afraid I don't know the FE enough to further improve this warning
> > without breaking valid programs, so the other possibility for me is just to
> > back out the original patch and leave this can of worms to you/Jason.
> 
> All right; let's revert your original patch, then.  AIUI, that patch
> fixed an accepts-invalid problem; that's better than rejects-valid problems.

If you prefer that, here is a patch I've bootstrapped/regtested on
x86_64-linux.

	Jakub

[-- Attachment #2: Z93 --]
[-- Type: text/plain, Size: 2939 bytes --]

2007-12-10  Jakub Jelinek  <jakub@redhat.com>

	PR c++/34238
	* decl2.c (cp_write_global_declarations): Revert 2007-11-22 change.

	* g++.dg/ext/visibility/anon7.C: Add xfail.
	* g++.dg/ext/visibility/anon9.C: New test.
	* g++.dg/ext/visibility/anon10.C: New test.

--- gcc/cp/decl2.c.jj	2007-12-09 22:25:40.000000000 +0100
+++ gcc/cp/decl2.c	2007-12-09 22:29:59.000000000 +0100
@@ -3366,21 +3366,7 @@ cp_write_global_declarations (void)
 	  /* If this static data member is needed, provide it to the
 	     back end.  */
 	  if (DECL_NOT_REALLY_EXTERN (decl) && decl_needed_p (decl))
-	    {
-	      /* Error on
-		 namespace { struct A { static int i; }; }
-		 int foo () { return A::i; }
-		 without A::i definition (which can't be defined in
-		 a different CU because of the anonymous namespace).
-		 Don't do this if DECL_INITIAL is set, because for
-		 namespace { struct A { static const int i = 4; } };
-		 decl_needed_p won't reliably detect whether it was
-		 really needed.  */
-	      if (DECL_IN_AGGR_P (decl) && DECL_INITIAL (decl) == NULL_TREE)
-		error ("%Jstatic data member %qD used, but not defined",
-		       decl, decl);
-	      DECL_EXTERNAL (decl) = 0;
-	    }
+	    DECL_EXTERNAL (decl) = 0;
 	}
       if (VEC_length (tree, pending_statics) != 0
 	  && wrapup_global_declarations (VEC_address (tree, pending_statics),
--- gcc/testsuite/g++.dg/ext/visibility/anon7.C.jj	2007-11-20 19:12:40.000000000 +0100
+++ gcc/testsuite/g++.dg/ext/visibility/anon7.C	2007-12-09 20:54:27.000000000 +0100
@@ -5,7 +5,7 @@ namespace
 {
   struct A {
     static int bar ();
-    static int i;		// { dg-error "used, but not defined" }
+    static int i;		// { dg-error "used, but not defined" "" { xfail *-*-* } }
     static int j;
     static int k;
     static int l;
--- gcc/testsuite/g++.dg/ext/visibility/anon9.C.jj	2007-12-04 20:44:19.000000000 +0100
+++ gcc/testsuite/g++.dg/ext/visibility/anon9.C	2007-12-04 20:44:19.000000000 +0100
@@ -0,0 +1,11 @@
+// PR c++/34238
+// { dg-do compile }
+
+namespace
+{
+  template <typename T = int> struct A
+  {
+    static const bool a = true;
+  };
+}
+struct A<> a;
--- gcc/testsuite/g++.dg/ext/visibility/anon10.C.jj	2007-12-05 15:07:46.000000000 +0100
+++ gcc/testsuite/g++.dg/ext/visibility/anon10.C	2007-12-05 15:05:16.000000000 +0100
@@ -0,0 +1,44 @@
+// http://bugzilla.redhat.com/411871
+// { dg-do compile }
+
+extern "C" int printf (const char *, ...);
+
+struct E
+{
+  template <typename T> E (const volatile T&);
+  template <typename T> E (T&);
+  char x[64];
+};
+
+template<typename T> struct D
+{
+  static E foo (E, ...);
+  static int foo (T, int);
+};
+
+template<typename T, typename U> struct C
+{
+  static T ca;
+  static const int value = sizeof (D<U>::foo (ca, 0)) == sizeof (int);
+};
+
+struct A
+{
+  int a;
+};
+
+namespace
+{
+  struct B
+  {
+    int a;
+  };
+}
+
+int bar (void)
+{
+  C<A, int> a;
+  C<B, int> b;
+
+  return a.value + b.value;
+}

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR  c++/34238, c++/34340)
  2007-12-10 13:19         ` Jakub Jelinek
@ 2007-12-10 20:51           ` Mark Mitchell
  2007-12-17 17:19           ` Jason Merrill
  1 sibling, 0 replies; 8+ messages in thread
From: Mark Mitchell @ 2007-12-10 20:51 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Jason Merrill, gcc-patches

Jakub Jelinek wrote:
> On Fri, Dec 07, 2007 at 12:52:31PM -0800, Mark Mitchell wrote:
>> Jakub Jelinek wrote:
>>
>>>>   namespace { struct A { static int i; }; }
>>>>   static int foo() { return A::i; }
>>>>
>>>> the program is still erroneous, even though the compiler may likely
>>>> optimize away foo, and the reference to A::i.
>>> That's true, but the standard explicitly says the diagnostic is not
>>> required.
>> It does?  Where?  (I'm not disagreeing, I'm just surprised, and I
>> couldn't find a pointer.)
> 
> [class.static.data]/5:
> "There shall be exactly one definition of a static data member that is used in a program; no diagnostic is required; see 3.2."

Thanks.

However, I would suspect that there is also something that says that if
you use the value of a variable (whether a static data member or not),
the variable must be defined in the program.  I'm sure that you're
right, though, thinking a bit more about it; that probably says that no
diagnostic is required too.

> The patch I posted last Wednesday diagnosed the errors basically for the
> same stuff that ld would diagnose it, if anon namespace was not involved.
> When all uses are optimized out, etc., ld will not error nor warn either.
> 
>>> that should be warned about.  If we have some bit which we can really rely
>>> on to be set reliably for these purposes, then the warning can be precise,
>>> but TREE_USED is unfortunately not it.
>> TREE_USED should be accurate.  It should tell us whether or not a thing
>> was used by the input.  If TREE_USED is not set when it should be, or
>> set when it shouldn't be, we have a problem.
> 
> But it is set e.g. when seen in sizeof as shown on that boost snippet.

Hmph, I see.  I suspect that the standard itself isn't consistent on
this point.  For example, there is language that says that if you use
the name of a member in a class definition, the member name must refer
to the same thing after the definition.  For example:

  const int i = 7;
  struct S {
     int a[i];
     static const int i = 3;
  };

is erroneous.  But, surely:

  int i;
  struct S {
     int a[sizeof(i)];
     double i;
  };

is also erroneous.  So, in this context "use" must mean what TREE_USED
is meaning.

Frankly, I think the Boost code is trying too hard to be clever.
Defining the variable is not a big deal, and if the compiler can pull
out all references to the variable, it can pull out the variable too!
But, what I think doesn't necessarily matter...

>>> I'm afraid I don't know the FE enough to further improve this warning
>>> without breaking valid programs, so the other possibility for me is just to
>>> back out the original patch and leave this can of worms to you/Jason.
>> All right; let's revert your original patch, then.  AIUI, that patch
>> fixed an accepts-invalid problem; that's better than rejects-valid problems.
> 
> If you prefer that, here is a patch I've bootstrapped/regtested on
> x86_64-linux.

OK, please apply that.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR  c++/34238, c++/34340)
  2007-12-10 13:19         ` Jakub Jelinek
  2007-12-10 20:51           ` Mark Mitchell
@ 2007-12-17 17:19           ` Jason Merrill
  1 sibling, 0 replies; 8+ messages in thread
From: Jason Merrill @ 2007-12-17 17:19 UTC (permalink / raw)
  To: Jakub Jelinek; +Cc: Mark Mitchell, gcc-patches

It seems safe to give the error if DECL_SYMBOL_REFERENCED 
(DECL_ASSEMBLER_NAME) is set, just decl_needed_p is too strong a test.

Jason

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2007-12-17 17:02 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-11-27  4:17 [C++ PATCH] Fix a regression introduced by my PR34094 fix (PR c++/34238) Jakub Jelinek
2007-12-05 15:03 ` [C++ PATCH] Fix regressions introduced by my PR34094 fix (PR c++/34238, c++/34340) Jakub Jelinek
2007-12-07  4:31   ` Mark Mitchell
2007-12-07  7:53     ` Jakub Jelinek
2007-12-07 20:52       ` Mark Mitchell
2007-12-10 13:19         ` Jakub Jelinek
2007-12-10 20:51           ` Mark Mitchell
2007-12-17 17:19           ` Jason Merrill

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).