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);
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
--- 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
> > 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
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
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
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
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
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
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.
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
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
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
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
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
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
16 matches
Mail list logo
