I just noticed that the C and C++ compiler output pointer types differently:
Consider
int i;
printf("%p", &i);
When compiled as C that gives the warning
format '%p' expects argument of type 'void *', but argument 2 has type 'int *'
but when compiled as C++ it gives the warning
format '%p' exp
On Wed, 2012-06-27 at 05:01 -0700, H.J. Lu wrote:
> On Tue, Jun 26, 2012 at 10:56 PM, Mark Butler wrote:
> >
> >
> > On Tuesday, June 26, 2012 3:22:45 PM UTC-6, H.J. wrote:
> >>
> >> On Tue, Jun 26, 2012 at 2:11 PM, Mark Butler wrote:
> >> >
> >> >> x32 is designed to replace ia32 where long is 32
Hello.
I noticed that (foo.cpp):
enum gaz { foo, };
generated a warning
foo.cpp:1:15: warning: comma at end of enumerator list [-pedantic]
when compiled with
g++ -std=gnu++0x -pedantic -fsyntax-only foo.cpp
According to n3290 this is acceptable so I tried to make this warning go
away.
This
On Mon, 2010-09-20 at 10:39 +0200, Rodrigo Rivas wrote:
> > This is quite unreadable and not very informative.
> Totally agree.
>
> > Here there are two problems...
> > snipped
>
> I think that you are taking the wrong approach: you call
> "cp_parser_range_for" with C++98 and then if such a loop
Hello.
At the moment compilation of a range-based for in c++98 fails with the
error message:
foo.cpp: In function 'int foo()':
foo.cpp:4:13: error: expected initializer before ':' token
foo.cpp:6:1: error: expected primary-expression before '}' token
foo.cpp:6:1: error: expected ';' before '}' to
On Fri, 2010-06-11 at 08:44 +0800, yuanbin wrote:
> typedef struct CBase { int i; } CBase;
> typedef struct CT1 { EXTENDS(CBase) ... } CT1;
> typedef struct CT2 { EXTENDS(CT1) ... } CT2;
> ...
> typedef struct CTN { EXTENDS(CTN_1) ... } CTN;
> CTN t;
> t.i=1; //need not t.CTN_1CT2.CT1.CBase.i -
I recently ended up in a discussion about the -pthread flag at work and
when looking at the documentation I noticed that it is defined onlt for
SPARC and RS/6000/PowerPC.
Additionally -fopenmp and -ftree-parallelize-loops say they are only
supported on targets where -pthread are available.
Now, o
On Fri, 2010-03-05 at 15:07 -0800, Joe Buck wrote:
> On Fri, Mar 05, 2010 at 02:40:44PM -0800, Magnus Fromreide wrote:
> > On Fri, Mar 05, 2010 at 12:06:01PM -0800, Joe Buck wrote:
> > > On Fri, Mar 05, 2010 at 11:38:23AM -0800, Magnus Fromreide wrote:
> > > > Hello.
On Fri, Mar 05, 2010 at 12:06:01PM -0800, Joe Buck wrote:
> On Fri, Mar 05, 2010 at 11:38:23AM -0800, Magnus Fromreide wrote:
> > Hello.
> >
> > I tried to do
> >
> > for (;; ({ break; }))
> > printf("Hello\n");
> >
> > and got
Hello.
I tried to do
for (;; ({ break; }))
printf("Hello\n");
and got an error message:
error: break statement not within loop or switch
when compiling it as C. Given that 9899:1999 §6.8.6.3 says that a break
statement only shall appear in or as a switch or loop body that is expected.
Hello.
I tried to look at fixing DR/354 but ended up lost in cp/parser.c
I have the following test case:
template struct S { };
S<(int*)0> s;
and end up with the following errors
:2:9: error: a cast to a type other than an integral or enumeration type
cannot appear in a constant-expression
:2
On Fri, 2009-08-28 at 18:12 -0300, Pedro Lamarão wrote:
> 2009/8/11 Pedro Lamarão :
>
> > I've recently started my contributions to the gcc-in-cxx project, and
> > eventually decided on the qsort suggestion because it seems the
> > easiest one.
>
> Attached is a much more extensive patch replacin
On tis, 2008-05-13 at 15:03 +0100, Joern Rennecke wrote:
> With my current email setup and the volume of the gcc mailing list,
> it is not desirable to be to be subscribed to the gcc mailing list,
> I rather read the web archives.
I have read the list like that for years.
> However, this does not
On ons, 2007-08-29 at 16:42 -0400, Daniel Drake wrote:
> Hi,
>
> Take the following code sample:
>
>
> #define BREAK_GCC4_2
>
> template
> void foo(Op& op) { op(); }
>
> class My {
> public:
> static void myOp() { }
>
> void test() {
> #ifde
On fre, 2007-01-05 at 12:53 -0800, H. J. Lu wrote:
> On Fri, Jan 05, 2007 at 09:27:35PM +0100, Magnus Fromreide wrote:
> > On fre, 2007-01-05 at 17:05 +, Andrew Haley wrote:
> > > Magnus Fromreide writes:
> > >
> > > But it can't unless
On fre, 2007-01-05 at 17:05 +, Andrew Haley wrote:
> Magnus Fromreide writes:
>
> But it can't unless you use an architecture that has cmpxchgl.
> cmpxchgl is a 486 instruction; if you compile for 386, we have to
> generate the call because there is no such instruction.
I got so happy when __sync_bool_compare_and_swap showed up in 4.1 but
now HEAD have changed the behaviour for me.
Earlier I got (gcc version 4.1.2 20061028 (prerelease) (Debian
4.1.1-19)) (Yes, vendor version, but gcc.gnu.org versions did the same)
lock
cmpxchgl%edx, (%ecx
On tor, 2006-09-21 at 23:10 -0500, Peter Bergner wrote:
> On Thu, 2006-09-21 at 23:54 -0400, Jack Howarth wrote:
> > Peter,
> > Wouldn't we want something like...
>
> >
> > +#ifdef __powerpc64__
> > +unsigned long FindTopOfStack(unsigned long stack_start) {
> > +#else
> > unsigned long FindT
18 matches
Mail list logo
