Re: Intermittent/non-reproducible gcc testsuite failures

2009-04-13 Thread Michael Eager
Dave Korn wrote: Michael Eager wrote: Does anyone have any suggestions on how to get one of these tests to fail consistently, or a different approach to finding the cause of the intermittent failures? Perhaps hack the testsuite to run the tests under gdb, setting a breakpoint on abort() tha

messaging

2009-04-13 Thread Arthur Schwarz
In the following code fragment: # include # include # include using namespace std; void CommandLine(int argc, char** argv); int main(int argc, char** argv) { CommandLine(argc, argv[]); ifstream x.open(argv[1], ios:in); ofstream y.open(argv[1], ios::in); return 0; }; g++-4 mes

messages

2009-04-13 Thread Arthur Schwarz
Some messaging observations for the input code (below). # include # include # include using namespace std; void CommandLine(int argc, char** argv); int main(int argc, char** argv) { string a = "output.txt"; string* b = &a; ofstream y; y.open("output.txt", ios::in); y.open( a

Re: messages

2009-04-13 Thread Dave Korn
Arthur Schwarz wrote: > using namespace std; > void CommandLine(int argc, char** argv); > int main(int argc, char** argv) { >string a = "output.txt"; >string* b = &a; >ofstream y; >y.open("output.txt", ios::in); >y.open( a, ios::in); >y.open( a.c_str(), i

Re: question on 16 bit registers with 32 bit pointers

2009-04-13 Thread Michael Meissner
On Sat, Apr 11, 2009 at 01:40:57AM +0100, Dave Korn wrote: > Stelian Pop wrote: > > >>> Do I need to define movsi3(), addsi3() etc. patterns manually or should > >>> GCC > >>> figure those by itself ? > >> Not sure I understand you. You always need to define movMM3 etc. GCC > >> will > >> co

Re: messages

2009-04-13 Thread Arthur Schwarz
Thanks Dave;' Acerbic comments below. --- On Mon, 4/13/09, Dave Korn wrote: > > using namespace std; > > void CommandLine(int argc, char** argv); > > int main(int argc, char** argv) { > >    string  a = "output.txt"; > >    string* b = &a; > >    ofstream y; > >    > y.open("output.txt",   ios

Re: question on 16 bit registers with 32 bit pointers

2009-04-13 Thread Dave Korn
Michael Meissner wrote: > On Sat, Apr 11, 2009 at 01:40:57AM +0100, Dave Korn wrote: >> Stelian Pop wrote: >> > Do I need to define movsi3(), addsi3() etc. patterns manually or > should GCC figure those by itself ? Not sure I understand you. You always need to define movMM3 etc.

Re: messages

2009-04-13 Thread Dave Korn
Arthur Schwarz wrote: > Thanks Dave;' > > Acerbic comments below. G'wan, I can take it! >> Isn't that exactly what the compiler IS doing, as >> indicated by "candidates are ... "? > > I don't think so. [ ... ] A clear message that arg is wrong I think > is a better approach. But may

Re: messages

2009-04-13 Thread Joe Buck
On Mon, Apr 13, 2009 at 03:53:04PM -0700, Dave Korn wrote: > Nonono; I didn't mean to impugn anything you're doing, just trying to point > out that it's not easy. Your suggestions are all valid and good ideas, but > before they can be usefully incorporated into the compiler, they need to be > ex

Re: align of local char array seem not work.

2009-04-13 Thread Jim Wilson
Bernd Roesch wrote: char buf[256] __attribute__((aligned(16))); printf("%x\n",&buf[0]); this short test program give no error or warning and do not align as expect.i test with several 68k amigaos compilers (3.4.0 /4.3.2/4.4.0) Most likely gcc did align it, but one of the assembler, linker, o

Re: align of local char array seem not work.

2009-04-13 Thread Andrew Pinski
On Thu, Apr 9, 2009 at 6:07 AM, Bernd Roesch wrote: > Hi, > > i see simular lines in a program. > > char buf[256] __attribute__((aligned(16))); >   printf("%x\n",&buf[0]); This is PR 16660. Thanks, Andrew Pinski

Re: question on 16 bit registers with 32 bit pointers

2009-04-13 Thread Hans-Peter Nilsson
On Mon, 13 Apr 2009, Dave Korn wrote: > Michael Meissner wrote: > > On Sat, Apr 11, 2009 at 01:40:57AM +0100, Dave Korn wrote: > >> Stelian Pop wrote: > >> > > Do I need to define movsi3(), addsi3() etc. patterns manually or > > should GCC figure those by itself ? ... > > Though if you use

Re: messages

2009-04-13 Thread Arthur Schwarz
> > Thanks Dave;' > > > > Acerbic comments below. > > >>   Isn't that exactly what the > compiler IS doing, as > >> indicated by "candidates are ... "? > > > >   I don't think so. [ ... ] A clear > message that arg is wrong I think > >   is a better approach. > >   But maybe arg is right an

Re: messages

2009-04-13 Thread Arthur Schwarz
--- On Mon, 4/13/09, Joe Buck wrote: them all. > > Consider > > #include > struct Foo { int bar;}; > int main() { >   std::cerr << Foo(); > } > > Try it, the result is ugly, and I often encounter this one (Personal opinion - not to be construed as wisdom). The issue with the result i

Re: messages

2009-04-13 Thread Dave Korn
Joe Buck wrote: > And this, of course, means we have to define relevance. There are two > cases: the first is when we fail to choose an overload because of > ambiguity; there we can just report all of the choices that are tied for > "equally good". The other case is where no overload matches. T

Re: messaging

2009-04-13 Thread Kai Henningsen
Arthur Schwarz schrieb: In the following code fragment: # include # include # include using namespace std; void CommandLine(int argc, char** argv); int main(int argc, char** argv) { CommandLine(argc, argv[]); ifstream x.open(argv[1], ios:in); ofstream y.open(argv[1], ios::in);