Re: GCC spec posting on AMD Barcelona
Andrew Walrond wrote: Michael Meissner wrote: We have performance results that show GCC now delivers outstanding performance on AMD's Quad-core Barcelona processors. We've just posted our SPECint results tests with GCC 4.1.2 on AMD's Quad-core Barcelona processors. We just want to thank all of you for doing such a great job on the performance front. Our posted benchmark results are at http://developer.amd.com/gcc. Solid support for the gnu toolchain and linux kernel is a _fundamental_ requirement when I make buying decisions. Well done, AMD. I hope your competitors are listening. Some of them are woefully inadequate in this regard. Andrew Walrond Can't we remove this kind of message to some advocacy list. It is really just noise on the gcc development list.
Re: GCC spec posting on AMD Barcelona
Robert Dewar wrote: > > Can't we remove this kind of message to some advocacy list. It is really > just noise on the gcc development list. > When I berate the likes of Sun for not contributing, it would be hypocritical not to welcome and encourage enthusiastic support from others. The politics are unfortunately as important as the development details in this game, if we want a strong and vital toolchain development community. But rest assured that I am sensitive to the purpose of the list and I promise; no more off-topic posts from me for at least a couple of months :) Regards, Andrew Walrond
Inconsistent error/pedwarn: ISO C++
We can't seem to decide whether ISO C++ really forbids comparisons
between pointers and integers or not. The first two are for == and !=,
the second two are for <, >, <=, >=. Why the inconsistency?
typeck.c: error ("ISO C++ forbids comparison between pointer
and integer");
typeck.c: error ("ISO C++ forbids comparison between pointer
and integer");
typeck.c: pedwarn ("ISO C++ forbids comparison between
pointer and integer");
typeck.c: pedwarn ("ISO C++ forbids comparison between
pointer and integer");
- Doug
RE: [wwwdocs] Patch for RE: Coding conventions -- command line option vs command-line option
On 19 September 2007 23:31, Gerald Pfeifer wrote: > I am committing the patch below to our coding conventions and will fix > up the existing web pages accordingly. Amusingly enough, this just came out today: http://news.bbc.co.uk/1/hi/magazine/7004661.stm cheers, DaveK -- Can't think of a witty .sigline today
Bug in gcc: assignment to non-lvalue
Hello all,
I think the gcc compiler should not accept assignments to non-lvalues.
gcc does this however, but does not execute the assignment (probably the
assignment is executed on a copy, but that copy is entirely floating).
Here is my code:
#include
#include
#include
template class SuperArray
{
T **block;
int size;
public:
SuperArray() { block = (T **) calloc (32768, sizeof(T *)); if (!block)
exit (1); size = 0; }
void Wipe() { int k; for (k=0; k<=size-1>>16; k++) free (block[k]);
size = 0; }
~SuperArray() { int k; for (k=0; k<=size-1>>16; k++) free (block[k]);
free (block); }
T /*&*/operator[] (int index)
{
if (index < 0) exit (1); // range check for debugging
if (index < size) return block[index>>16][index&65535];
if (index > size) exit (1); // range check for debugging
// size must increase
int k;
for (k=(size-1>>16)+1; k<=(index>>16); k++)
{
block[k] = (T *) calloc (65536, sizeof (T));
if (!block[k]) exit (1);
}
size = index + 1;
return block[index>>16][index&65535];
}
T *operator+ (int index)
{
if (index < 0) exit (1); // range check for debugging
if (index < size) return block[index>>16] + (index&65535);
if (index > size) exit (1); // range check for debugging
// size must increase
int k;
for (k=(size-1>>16)+1; k<=(index>>16); k++)
{
block[k] = (T *) calloc (65536, sizeof (T));
if (!block[k]) exit (1);
}
size = index + 1;
return block[index>>16] + (index&65535);
}
};
struct string100 { char value[100]; };
main ()
{
SuperArray a;
strcpy ((a + 0)->value, "No assignment.");
strcpy (a[0].value, "Non-lvalue assignment."); // illegal
printf ("%s\n", (a + 0)->value);
}
Re: Bug in gcc: assignment to non-lvalue
On 9/20/07, Michiel de Bondt <[EMAIL PROTECTED]> wrote:
> struct string100 { char value[100]; };
> strcpy (a[0].value, "Non-lvalue assignment."); // illegal
So you basically have:
a.operator[](0).value
Where value ia an array, I cannot remember the specific rules here but
value decays to &value[0] which is considered a rvalue but value[0] is
a lvalue even if a.operator[](0) is an rvalue.
So I think GCC is correct in accepting this code.
Thanks,
Andrew Pinski
g++ 4.3.0 error: changes meaning
I'm testing our C++ code with
g++ (GCC) 4.3.0 20070919 (experimental)
That's SVN revision 128608, gcc_trunk.
I'm getting many errors like this:
% g++ -c changes_meaning.cpp
changes_meaning.cpp:8: error: declaration of 'typedef struct ns::foo
ns::bar::foo'
changes_meaning.cpp:4: error: changes meaning of 'foo' from 'struct
ns::foo'
A minimal reproducer is below.
Compilation works with *many* other compilers incl. all older, released g++,
Visual C++, and EDG-based compilers.
Also, if I make this change it works with g++ 4.3.0:
< typedef foo foo;
---
> typedef ns::foo foo;
I spent some time with Google and also looked here:
http://gcc.gnu.org/gcc-4.3/changes.html
But I couldn't find an indication that the new error is intentional.
Is it?
Thanks!
Ralf
namespace ns {
template
struct foo {};
struct bar
{
typedef foo foo;
};
}
Don't let your dream ride pass you by. Make it a reality with Yahoo! Autos.
http://autos.yahoo.com/index.html
function overloading and variadic arguments
hello,
today i've spent a few hours debugging... consider the following code:
>8>8>8>8>8>8
// test.cpp
#include
#include
int prn(const char* fmt_);
int prn(const char* fmt_, ...) __attribute__((format(printf, 1, 2)));
int prn(const char* fmt_, va_list args_);
int prn(const char* fmt_)
{
return 0;
}
int prn(const char* fmt_, ...)
{
va_list args;
va_start(args, fmt_);
int r = prn(fmt_, args);
va_end(args);
return r;
}
int prn(const char* fmt_, va_list args_)
{
char out[4096];
return vsnprintf(out, sizeof(out), fmt_, args_);
}
int main(int argc_, char** argv_)
{
int s0 = prn("%s %s", "hello", "world");
int s1 = prn("hello %s", "world");
int s2 = prn("hello %s", argv_[0]);
int s3 = prn("hello %d", 42);
return 0;
}
>8>8>8>8>8>8
it turns out, that when initializing s1, the function with the va_list
second arg is called, not the variadic version, which results in a sigsegv.
tried gcc-2.95, 3.3, 4.1 and 4.2, with -Wall -W[extra]. 4.2 warns about
the deprecated conversion from string constant to char* (which needs
some interpretation), but the others are silent about the issue.
a warning would be nice, if the compiler detects that there's an
ambiguity: passing an argument that would fit the variadic and the
va_list (or any other type) argument versions of the functions, too.
the solution is to name the functions differently, but unfortunately
pinning down the source of the bug took me quite some time (the original
code was more complex of course ;)
i'd like to hear your comments.
regards, p
Re: g++ 4.3.0 error: changes meaning
On 9/20/07, Ralf W. Grosse-Kunstleve <[EMAIL PROTECTED]> wrote: > Compilation works with *many* other compilers incl. all older, released g++, > Visual C++, and EDG-based compilers. And that does not make the code valid. > I spent some time with Google and also looked here: > http://gcc.gnu.org/gcc-4.3/changes.html > But I couldn't find an indication that the new error is intentional. > Is it? Yes it is intentional. It is an extension of an already existing error with non templates. The code is invalid, though the C++ standard does make a mention, this does not have to be diagnostic. Thanks, Andrew Pinski
Understanding Macro Pre-processor
Hi All. I'm using GCC until I use Linux, and I've always used the compiler and the C language just basically. I've been made too basic usage of pre-processor macros(some constants, conditionals, and other)... For my surprise, it works different than I've always imagined... To me, it simply "subst" the text at compile-time. Since I'm training to the ACM, I've been noted hints about using macros to make the processing fast. So I think it's happen because the macros are replaced at compile time... And just it. Bu I've been made some tests... By example... A macro: #define mul(X,Y) (X*Y) It makes the processing faster... But I've passed vars which I've obtained at the runtime! So I think: int a,b,c; cin>>a; cin>>b c=mul(a,b) The mul(a,b) is replaced by a*b; But... Why executing that a milion of times is faster than using the simple a*b itself??? It really happens? Why? Thanks in the advance! Bruno M. Guedes
Re: g++ 4.3.0 error: changes meaning
Andrew Pinski wrote: > Yes it is intentional. It is an extension of an already existing > error with non templates. The code is invalid, though the C++ > standard does make a mention, this does not have to be diagnostic. Thanks for the quick reply! This is great, I like the change since it enforces improved readability. However, I anticipate that many people will have to make changes. Specifically, I have to go into the Boost.Python sources. If people ask about my changes, it would help if I could point them to some gcc resource. For example, could the "Changes" page at http://gcc.gnu.org/gcc-4.3/changes.html be updated to mention the new error? Thanks! Ralf Shape Yahoo! in your own image. Join our Network Research Panel today! http://surveylink.yahoo.com/gmrs/yahoo_panel_invite.asp?a=7
Re: g++ 4.3.0 error: changes meaning
On 9/20/07, Ralf W. Grosse-Kunstleve <[EMAIL PROTECTED]> wrote: > Andrew Pinski wrote: > > Yes it is intentional. It is an extension of an already existing > > error with non templates. The code is invalid, though the C++ > > standard does make a mention, this does not have to be diagnostic. > > Thanks for the quick reply! This is great, I like the change since it > enforces improved readability. However, I anticipate that many people > will have to make changes. Specifically, I have to go into the > Boost.Python sources. If people ask about my changes, it would help > if I could point them to some gcc resource. For example, could the > "Changes" page at http://gcc.gnu.org/gcc-4.3/changes.html be updated > to mention the new error? FYI, with -fpermissive gcc will accept the code. Richard.
Re: Understanding Macro Pre-processor
On Thu, 2007-09-20 at 16:43 -0300, Bruno Moreira Guedes wrote: > I'm using GCC until I use Linux, and I've always used the compiler and > the C language just basically. > I've been made too basic usage of pre-processor macros(some constants, > conditionals, and other)... This list is about development of GCC, not using GCC or the C programming language. Please try asking a newsgroup like comp.lang.c, or the gcc-help mailing list. Thanks, Ben
Re: Bug in gcc: assignment to non-lvalue
Using strings to show my point was not a good idea. You can add a field
"int number" to the struct and perform similar operations (with =
instead of strcpy).
But even with strings, gcc should give an error like: "strcpy(const
char*, const char*) does not exists". In case of a "typedef char
string100[100]", gcc behaves correctly by ringing alarm bells. So it
seems to be the . operator that behaves incorrectly.
If you replace /*&*/ by & in the SuperArray class, the program becomes
correct (in my opinion), but also the effect of the program becomes
different.
Regards, Michiel
Andrew Pinski schreef:
On 9/20/07, Michiel de Bondt <[EMAIL PROTECTED]> wrote:
struct string100 { char value[100]; };
strcpy (a[0].value, "Non-lvalue assignment."); // illegal
So you basically have:
a.operator[](0).value
Where value ia an array, I cannot remember the specific rules here but
value decays to &value[0] which is considered a rvalue but value[0] is
a lvalue even if a.operator[](0) is an rvalue.
So I think GCC is correct in accepting this code.
Thanks,
Andrew Pinski
