On Mon, Nov 29, 2010 at 4:20 PM, Ian Lance Taylor wrote:
> We could decide not to do anything about this, but I don't think it's a
> non-issue. With -std=gnu++98 g++ accepts this invalid code. That is,
> it is a g++ extension, and the code is properly rejected with
> -pedantic-errors. We could
Ian Lance Taylor writes:
> We could decide not to do anything about this, but I don't think it's a
> non-issue. With -std=gnu++98 g++ accepts this invalid code. That is,
> it is a g++ extension, and the code is properly rejected with
> -pedantic-errors. We could decide to carry the extension fo
On 11/29/2010 08:52 PM, Paul Koning wrote:
I'm doing some experiments to get to know GCC better, and something is puzzling
me.
I have defined an md file with DFA and costs describing the fact that loads
take a while (as do stores). Also, there is no memory to memory move, only
memory to/from
I'm doing some experiments to get to know GCC better, and something is puzzling
me.
I have defined an md file with DFA and costs describing the fact that loads
take a while (as do stores). Also, there is no memory to memory move, only
memory to/from register.
Test program is basically a=b; c=d
Gabriel Dos Reis writes:
> On Mon, Nov 29, 2010 at 3:24 PM, Roman Kononov wrote:
>> $ cat test.cc
>> struct X { static float const v=1; };
>>
>> $ g++ -c -std=gnu++0x test.cc
>> test.cc:1:33: error: 'constexpr' needed for in-class initialization of
>> static data member 'v' of non-integral type
"David Mathog" writes:
> I tried to track down the bug mentioned previously in testing my
> software SSE2 when compiled with -m64 and ended up removing all
> of the CHECK and my own includes without eliminating the bug. The test
> program works fine with -m32, or with -m64 -msse2, but it fails
Ian Lance Taylor writes:
> Basile Starynkevitch writes:
>
>> @@ -13358,7 +13358,7 @@
>> *) ok=no ;;
>>esac
>>case ,${enable_languages}, in
>> -*,c++,*) ;;
>> +*, c++,*) ;;
>> *) ok=no ;;
>>esac
>>if test $ok = yes; then
>
> I don't know why you are
Basile Starynkevitch writes:
> @@ -13358,7 +13358,7 @@
> *) ok=no ;;
>esac
>case ,${enable_languages}, in
> -*,c++,*) ;;
> +*, c++,*) ;;
> *) ok=no ;;
>esac
>if test $ok = yes; then
I don't know why you are getting this diff. You should not. I ca
On Mon, Nov 29, 2010 at 3:24 PM, Roman Kononov wrote:
> $ cat test.cc
> struct X { static float const v=1; };
>
> $ g++ -c -std=gnu++0x test.cc
> test.cc:1:33: error: 'constexpr' needed for in-class initialization of
> static data member 'v' of non-integral type
>
> This will break a great deal of
jovi zhang writes:
> Does gcc compiler support enumeration print support? what I means
> is like this:
>
> typedef struct {
> int ttype ;
> intt index ;
> } unit_it_t ;
>
> unit_it_t f_unit;
>
> GCC_PRINT(f_unit);
>
>
> Then compiler will print all filed of f_unit data structure automa
On Mon, 29 Nov 2010, Andrew Pinski wrote:
On Mon, Nov 29, 2010 at 1:24 PM, Roman Kononov wrote:
$ cat test.cc
struct X { static float const v=1; };
$ g++ -c -std=gnu++0x test.cc
test.cc:1:33: error: 'constexpr' needed for in-class initialization of
static data member 'v' of non-integral type
2010-11-29 13:25 CST, Andrew Pinski wrote:
>well this code is not valid C++03 code to begin with.
I agree. I mean "existing gnu++" if you will.
On Mon, Nov 29, 2010 at 1:24 PM, Roman Kononov wrote:
> $ cat test.cc
> struct X { static float const v=1; };
>
> $ g++ -c -std=gnu++0x test.cc
> test.cc:1:33: error: 'constexpr' needed for in-class initialization of
> static data member 'v' of non-integral type
>
> This will break a great deal of
$ cat test.cc
struct X { static float const v=1; };
$ g++ -c -std=gnu++0x test.cc
test.cc:1:33: error: 'constexpr' needed for in-class initialization of
static data member 'v' of non-integral type
This will break a great deal of existing c++ code preventing easy
transition to c++0x. Maybe, the
"David Mathog" writes:
> In my software SSE2 emulation I am currently using this sort of approach
> to extract data fields out of __m128i and __m128d vectors:
>
> #define EMM_SINT4(a) ((int *)&(a))
>
> static __inline __m128i __attribute__((__always_inline__))
> _mm_slli_epi32 (__m128i __A, int
I tried to track down the bug mentioned previously in testing my
software SSE2 when compiled with -m64 and ended up removing all
of the CHECK and my own includes without eliminating the bug. The test
program works fine with -m32, or with -m64 -msse2, but it fails with
-m64 -mno-sse2. Here is the
In my software SSE2 emulation I am currently using this sort of approach
to extract data fields out of __m128i and __m128d vectors:
#define EMM_SINT4(a) ((int *)&(a))
static __inline __m128i __attribute__((__always_inline__))
_mm_slli_epi32 (__m128i __A, int __B)
{
__v4si __tmp = {
EMM_SI
Hello
The function position_pass from gcc/passes.c is called when
registering a pass from a plugin.
It contains the following test
/* Check if the current pass is of the same type as the new pass and
matches the name and the instance number of the reference pass. */
if (pas
Basile Starynkevitch writes:
> % svn diff
> Index: configure
> ===
> --- configure (revision 167234)
> +++ configure (working copy)
> @@ -13358,7 +13358,7 @@
> *) ok=no ;;
>esac
>case ,${enable_languages}, in
> -*,
On 11/26/2010 11:12 PM, Uros Bizjak wrote:
> Hello!
>
>>> /home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
>>> In class 'gnu.java.awt.peer.gtk.GtkComponentPeer':
>>> /home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:
>>> I
Hello All,
[[this a bug I am encountering while merging the trunk into GCC MELT,
but I can reproduce it under trunk only, so I don"t speak of MELT
anymore; very probably I have bad versions of required utilities, but
I cannot find which]]
I have a pristine GCC trunk rev 167234 under /usr/src/Lan
On 11/29/2010 02:40 AM, John David Anglin wrote:
I have experienced a number of problems with the new bugzilla. It
seems "Reload current page" doesn't consistently update all fields
(e.g., Target Milestone). As a result, entering new comments, etc,
can corrupt fields that haven't been updated.
22 matches
Mail list logo
