public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* Is this a bug?
@ 1999-05-11 21:09 Christian II
  1999-05-11 23:44 ` Martin v. Loewis
  0 siblings, 1 reply; 18+ messages in thread
From: Christian II @ 1999-05-11 21:09 UTC (permalink / raw)
  To: egcs-bugs

Is this a bug in the compiler?
I am using version 1.1.2 of the egcs compiler; and when I compile the
following program in DOS or linux, I get this output:

test.cpp: In function `int main()':
test.cpp:33: no matching function for call to `Triangle::render (int, int,
int)'

test.cpp:27: candidates are: Triangle::render()


Shouldn't it call Object::render(float, float, float)?  Instead,
Triangle::render() overrides it!

Could you please E-mail me about this at: christianii@prodigy.net


// test program
class Object
{
public:
  virtual void move(float x, float y, float z);
  virtual void render();                        // render at origin
  void render(float x, float y, float z)        // render at x,y,z
    {move(x,y,z); render(); move(-x,-y,-z);}
};

class Triangle
{
  float v[3][3];
public:
  virtual void move(float x, float y, float z);
  virtual void render();
};

main()
{
  Triangle t;
  t.render(0, 0, -5);
}


^ permalink raw reply	[flat|nested] 18+ messages in thread
[parent not found: <007d01bf6988$d2fb0c40$795d608c@ccl.itri.org.tw>]
* Is this a bug?
@ 2000-01-30 16:44 Kuo Yu Chuang
  0 siblings, 0 replies; 18+ messages in thread
From: Kuo Yu Chuang @ 2000-01-30 16:44 UTC (permalink / raw)
  To: gcc-bugs

Good days, and sorry for the inconvenience I made ^_^
 
I don't know if this is a bug, or just a misunderstanding :-P
I am currently using the GCC as a corss-compiler which
target is VAX machine. The host is i386 arch with linux.
Here is the test program I wrote:
 
main( )
{
    unsigned int a, b;
    a = 10;
    b = 5;
 
    a = a % b;
}
 
In the VAX-assembly, it calls "umodsi3" to achieve mod of
the two unsigned integer. However, in libgcc1.c, the umodsi3
is also implemented in following statements:
 
#define perform_umodsi3(a, b) return a % b
nongcc_SI_type
__umodsi3 (a, b)
     unsigned nongcc_SI_type a, b;
{
  perform_umodsi3 (a, b);
}

As a result, we can't use this compiler to compile 
libgcc1.c in order to provide the unsigned integer mod.
This situation becames to a self-calling recurrsive. 
Some other machine is containing this umodsi3 in 
".md" file but Vax is not. Should we patch this one
to vax.md or in libgcc1?
(to emulate umodsi3 with signed integer?)
 
Thank you in advance :-)
 
==================
Kuo-Yu Slayer Chuang
Computer & Communications Research Laboratories
Software Engineer
Industrial Technology Research Institute, Taiwan.
E-mail: slayer@itri.org.tw
==================


^ permalink raw reply	[flat|nested] 18+ messages in thread
* Is this a bug?
@ 2000-12-06  3:42 Martin Kahlert
  0 siblings, 0 replies; 18+ messages in thread
From: Martin Kahlert @ 2000-12-06  3:42 UTC (permalink / raw)
  To: gcc-bugs

Hi!
I have code similar to this:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void f(const char **x)
{
 while(*x)
    {
     puts(*x);
     x++;
    }
}

int main(int argc,char *argv[])
{
 char **buffer;

 buffer = calloc(3, sizeof(char*));

 buffer[0] = strdup("Hello");
 buffer[1] = strdup("World");

 f(buffer);

 return 0;
}

gcc -Wall -o prog prog.c gives:

t.c: In function `main':
t.c:23: warning: passing arg 1 of `f' from incompatible pointer type
(the warning comes from the missing const)
Is this a bug?

At least it is an inconsistency:

f(const char *buffer)
{
 puts(buffer);
}

int main()
{
 char b[] = "Hello World";
 f(b);
 return 0;
}

works without any warning!

Thanks for any clarification,
Martin.


-- 
The early bird gets the worm. If you want something else for       
breakfast, get up later.
>From jsm28@cam.ac.uk Wed Dec 06 03:55:00 2000
From: "Joseph S. Myers" <jsm28@cam.ac.uk>
To: Martin Kahlert <martin.kahlert@infineon.com>
Cc: <gcc-bugs@gcc.gnu.org>
Subject: Re: Is this a bug?
Date: Wed, 06 Dec 2000 03:55:00 -0000
Message-id: <Pine.LNX.4.30.0012061150200.31115-100000@kern.srcf.societies.cam.ac.uk>
References: <20001206124239.A20108@keksy.muc.infineon.com>
X-SW-Source: 2000-12/msg00131.html
Content-length: 531

On Wed, 6 Dec 2000, Martin Kahlert wrote:

> t.c: In function `main':
> t.c:23: warning: passing arg 1 of `f' from incompatible pointer type
> (the warning comes from the missing const)
> Is this a bug?

No; you can pass a "char **" to a function expecting a "char **" or a
"char *const *", but not to one expecting a "const char **" or a "const
char *const *".  It's only at the first level of indirection that you can
have different type qualifiers in the expected type and the type passed.

-- 
Joseph S. Myers
jsm28@cam.ac.uk


^ permalink raw reply	[flat|nested] 18+ messages in thread
* Is this a bug?
@ 2002-08-30  2:41 Ritzert
  2002-09-03 14:07 ` Matt Austern
  0 siblings, 1 reply; 18+ messages in thread
From: Ritzert @ 2002-08-30  2:41 UTC (permalink / raw)
  To: gcc-bugs; +Cc: austern

Hi all,

Since 2002-08-26 I'm unable to compile STLPort with gcc HEAD. I have
stripped down the STLPort code to this small testcase:

# cat x.cpp
template <class _Tp>
inline const _Tp& max(const _Tp& __a, const _Tp& __b)
        { return __a < __b ? __b : __a; }

void append()
{
        const unsigned __old_size = 3;
        int __n = 7;
        max(__old_size, static_cast<unsigned>(__n));
}

# gcc -c x.cpp
x.cpp: In function `void append()':
x.cpp:9: error: non-lvalue in unary `&'

The patch causing this seems to be
2002-08-24  Matt Austern  <austern@apple.com>

	* tree.c (lvalue_p_1): Add argument for whether casts of lvalues
	are allowable.
	(real_lvalue_p): Update caller.
	(lvalue_p): Ditto.
	(non_cast_lvalue_or_else): New.
	* tree.h: Declare it.
	* typeck.c (build_unary_op): Use non_cast_lvalue_or_else.

The ChangeLog to the previous successful build is rather small with
this being the only patch that looks suspicious to me.

If this is considered a bug, just tell me and I'll file a bug report
for it. (Or fix it before I get the chance to do so ;-) ).

Regards,
Michael


^ permalink raw reply	[flat|nested] 18+ messages in thread
* Is this a bug?
@ 2003-01-02 21:21 Songtao Chen
  2003-01-02 21:24 ` Neil Booth
  0 siblings, 1 reply; 18+ messages in thread
From: Songtao Chen @ 2003-01-02 21:21 UTC (permalink / raw)
  To: gcc-bugs

Hi there,

It appears to be a bug to me.

* gcc version:
   gcc.c2.95.3

* source code: bug.c

#include<stdio.h>

int main(void)
{
    int r, i;

    i = 0;
    r = ++i % 2;
    printf("test 1 : r = %d, i = %d\n", r, i);

    i = 0;
    r = i++ % 2;
    printf("test 2 : r = %d, i = %d\n", r, i);

    i = 0;
    r = (++i) % 2;
    printf("test 3 : r = %d, i = %d\n", r, i);

    i = 0;
    r = (i++) % 2;
    printf("test 4 : r = %d, i = %d\n", r, i);

    i = 0;
    r = (i+1) % 2;
    printf("test 5 : r = %d, i = %d\n", r, i);

    return 0;
}

* compile command:
    gcc.c2.95.3 bug.c

* type of machine:

   SunOS ott-view1 5.6 Generic_105181-28 sun4u sparc SUNW,Ultra-Enterprise

...


* output :

test 1 : r = 1, i = 1
test 2 : r = 0, i = 1
test 3 : r = 1, i = 1
test 4 : r = 0, i = 1
test 5 : r = 1, i = 0

     Expecting r = 1 in test 4, because use of brackets.



Thanks,

Songtao


^ permalink raw reply	[flat|nested] 18+ messages in thread
* Is this a bug?
@ 2003-02-06 21:33 Matthew Toseland
  2003-02-06 22:18 ` Falk Hueffner
  0 siblings, 1 reply; 18+ messages in thread
From: Matthew Toseland @ 2003-02-06 21:33 UTC (permalink / raw)
  To: gcc-bugs

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

#include <stdio.h>

void main() {
        int x = 1;
        int y = x << 32;
        int z = (x << 32);
        int q = 32;
        printf("1 << 32 = %x = %x\n", (1L << 32), (1LL << 32));
	printf("1 << 32 = %x = %x\n", (1UL << 32), (1ULL << 32));
	printf("1 << 32 = %x = %x\n", (x << 32), (z << 32));
        printf("1 << 32 = %x = %%x\n", %(x << %q), (z %<< q));
}

Returns 

1 << 32 = 0 = 0
1 << 32 = 0 = 0
1 << 32 = 1 = 1
1 << 32 = 1 = 1


Is this the defined behaviour? (1L << 32) is different from (x << 32)
where x is an int defined to 1?
								
-- 
Matthew Toseland
toad@amphibian.dyndns.org/amphibian@users.sourceforge.net
Full time freenet hacker.
http://freenetproject.org/
Freenet Distribution Node (temporary) at http://amphibian.dyndns.org:8889/27rV~CifX54/
ICTHUS.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 18+ messages in thread
* RE: Is this a bug?
@ 2003-08-21  9:23 Lev Assinovsky
  0 siblings, 0 replies; 18+ messages in thread
From: Lev Assinovsky @ 2003-08-21  9:23 UTC (permalink / raw)
  To: Alexandre Oliva; +Cc: Gcc-Bugs (E-mail), Gcc-Help (E-mail)

The test case passed under gcc 3.3.1.
The problem was in lack of SOM weak support in gcc prior 3.3

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909


> -----Original Message-----
> From: Alexandre Oliva [mailto:aoliva@redhat.com]
> Sent: Tuesday, August 12, 2003 10:57 PM
> To: Lev Assinovsky
> Cc: Gcc-Bugs (E-mail); Gcc-Help (E-mail)
> Subject: Re: Is this a bug?
> 
> 
> On Aug 12, 2003, "Lev Assinovsky" 
> <LAssinovsky@algorithm.aelita.com> wrote:
> 
> > gcc 3.2.3, HPUX-11.00:
> 
> > t.cpp: In static member function `static const item* A::f()':
> > t.cpp:6: warning: sorry: semantics of inline function 
> static data `const item 
> >    arr[1]' are wrong (you'll wind up with multiple copies)
> > t.cpp:6: warning:   you can work around this by removing 
> the initializer
> 
> It's not as much of a bug, but rather a limitation AFAIK imposed by
> the object file of the platform you've chosen.  GCC requires weak
> symbols in order to implement this feature correctly, and 32-bit HP-UX
> object files don't support them (completely?).
> 
> -- 
> 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
> 


^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2003-08-21  9:23 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-05-11 21:09 Is this a bug? Christian II
1999-05-11 23:44 ` Martin v. Loewis
     [not found] <007d01bf6988$d2fb0c40$795d608c@ccl.itri.org.tw>
2000-01-30  2:45 ` Martin v. Loewis
2000-01-30 16:44 Kuo Yu Chuang
2000-12-06  3:42 Martin Kahlert
2002-08-30  2:41 Ritzert
2002-09-03 14:07 ` Matt Austern
2002-09-10  1:06   ` Michael Ritzert
2003-01-02 21:21 Songtao Chen
2003-01-02 21:24 ` Neil Booth
2003-01-02 21:42   ` Songtao Chen
2003-01-02 21:46     ` Neil Booth
2003-01-02 23:00       ` Songtao Chen
2003-01-13  5:17         ` Zack Weinberg
2003-01-13  5:17           ` Songtao Chen
2003-02-06 21:33 Matthew Toseland
2003-02-06 22:18 ` Falk Hueffner
2003-08-21  9:23 Lev Assinovsky

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