RE: -pedantic reports ambiguous base

2002-01-10 Thread Martin Dorey

Martin,

Thanks for looking at this.

10.1.4 has this example, which it claims is legal (incidentally my g++-3.0
-pedantic agrees):

struct L { int next; };
struct A : L {};
struct B : L {};
struct C : A, B { void f (); };
void C::f () { A::next = B::next; }

If your previous transformation were also applicable here, this would be
equivalent to "this->L::next = this->L::next;" - which is clearly not
well-formed.  Have I missed some relevant distinction in the Standard
between data member lookup and member function lookup?

While the Standard paragraph isn't exactly clear, I don't think that the
members of the set that is constructed under 10.2.2 can be of the form
"HwQueue's void pop() member".  Rather, they have to include information
about which subobject they involve.  In this way, the set produced by a
lookup for undecorated "pop();" would be:

{ "direct base class ISImq's direct base class HwQueue's void pop()", 
  "direct base class ISPmq's direct base class HwQueue's void pop()"}

Which isn't a singleton set, and so the program wouldn't be well-formed.

This all hinges on "name lookup begins in the scope of the
nested-name-specifier" implying something like "name lookup does not
consider sub-objects outside the scope of the nested-name-specifier".

Cheers,

-Original Message-
From: Martin v. Loewis [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 10, 2002 12:15 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; debian-gcc@lists.debian.org
Subject: Re: -pedantic reports ambiguous base


> Without -pedantic there is not even a warning (even with -W -Wall).

> 10.2.1 says "for a qualified-id, name lookup begins in the scope of
> 10.2.the nested-name-specifier".  In which scope, I don't think the
> 10.2.reference to pop() or HWQueue, for that matter, is ambiguous.

This is caused by the fragment in cp/init.c

  /* Convert 'this' to the specified type to disambiguate conversion
 to the function's context.  Apparently Standard C++ says that we
 shouldn't do this.  */
  if (decl == current_class_ref
  && ! pedantic
  && ACCESSIBLY_UNIQUELY_DERIVED_P (type, current_class_type))

It seems there are several interpretations of 10.2/1. GCC's
interpretation is that, indeed, lookup starts in ISPmq, and finds
HwQueue::pop. So the call you have written is equivalent to

  this->HwQueue::pop();

which is ambiguous.

It would be good if you could achieve independent clarification,
e.g. through comp.std.c++. If people are of different opinion there as
well, consider filing a Defect Report. Notice that variations of this
have been discussed repeatedly in comp.stdc.c++; you may want to read
the archives.

Regards,
Martin


*
This e-mail and any attachment is confidential. It may only be read, copied and 
used by the intended recipient(s). If you are not the intended recipient(s), 
you may not copy, use, distribute, forward, store or disclose this e-mail or 
any attachment. If you are not the intended recipient(s) or have otherwise 
received this e-mail in error, you should destroy it and any attachment and 
notify the sender by reply e-mail or send a message to [EMAIL PROTECTED]
*




Generates bad code for indirect function calls on pa-risc

2002-01-10 Thread Torsten Landschoff

>Submitter-Id:  net
>Originator:
>Organization:  Debian Project
>Confidential:  no
>Synopsis:  Generates bad code for indirect calls on pa-risc
>Severity:  serious
>Priority:  medium
>Category:  target
>Class: wrong-code
>Release:   3.0.3 (Debian testing/unstable)
>Environment:
System: Linux sarti 2.4.16-64 #1 Fri Dec 7 16:08:36 MST 2001 parisc64 unknown
Architecture: parisc64


host: hppa-unknown-linux-gnu
build: hppa-unknown-linux-gnu
target: hppa-unknown-linux-gnu
configured with: ../src/configure -v --enable-languages=c,c++,f77,proto,objc 
--prefix=/usr --infodir=/share/info --mandir=/share/man --enable-shared 
--with-gnu-as --with-gnu-ld --with-system-zlib --enable-long-long --enable-nls 
--without-included-gettext --disable-checking --enable-threads=posix 
--with-cpp-install-dir=bin hppa-linux
>Description:
The Ghostscript binary built with gcc 3.0.3 on pa-risc is incorrect. I 
tracked the problem to the code generated by gcc when calling a function
via a function pointer. Interestingly this only applies to the 
floating point arguments. Everything else seems to work fine. 

Here is what I consider a very nice example of the problem:

---
#include 
voidout(const char *str, double x)
{
printf("%s: %f\n", str, x);
}
int main(int argc, char **argv)
{
void(*f)(const char *, double) = out;
f("Calling via function pointer", 3.1415926535);
out("Calling directly", 3.1415926535);
return 0;
}
---

The output of this program is as follows:

---
[EMAIL PROTECTED]:~/gccbug$ gcc realind.c -o realind -lm
[EMAIL PROTECTED]:~/gccbug$ ./realind
Calling via function pointer: 0.00
Calling directly: 3.141593
---
>How-To-Repeat:
Building the program above should suffice for repeating the problem. Let
me know if it works on your system :)
>Fix:
I don't know a viable work around. You could avoid using function pointers
or pass the floating point values by reference.