Re: GCC Bugzilla with Firefox 3.6.12

[Tobias Burnus]

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.


I think that's a feature not a bug. There is a difference between Ctrl-R 
and Ctrl-Shift-R; the idea seems to be to keep the form content with a 
simple reload while a force reload also resets the form content.


I think that's a general Firefox feature and unrelated to Bugzilla; at 
least, I do not see any difference between the old and the new Bugzilla 
version in this regard.


Tobias

configure related issue: syntax error near unexpected token `c++

[Basile Starynkevitch]

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/Lang/gcc-trunk-bstarynk 

I want to regenerate its topmost ./configure so I run the following
commands under the source tree /usr/src/Lang/gcc-trunk-bstarynk


## clean up every auto* dirt
% rm -rf autom4te.cache */autom4te.cache 


### version of autogen, and then I run it
% autogen --version
autogen (GNU AutoGen) - The Automated Program Generator - Ver. 5.10
% autogen Makefile.def 

## version of autoconf, and then I run it
% autoconf --version
autoconf (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by David J. MacKenzie and Akim Demaille.
% autoconf


## go into GCC
cd gcc

## version of autoheader, and then run it
% autoheader --version
autoheader (GNU Autoconf) 2.64
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later

This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Roland McGrath and Akim Demaille.
% autoheader

## go back to topmost source directory
## ask for differences

 % svn diff 
Index: configure
===
--- configure   (revision 167234)
+++ configure   (working copy)
@@ -13358,7 +13358,7 @@
 *) ok=no ;;
   esac
   case ,${enable_languages}, in
-*,c++,*) ;;
+*, c++,*) ;;
 *) ok=no ;;
   esac
   if test $ok = yes; then


##

And then of course running the regenerated configure fails.
checking for the correct version of the gmp/mpfr/mpc libraries... yes
checking for version 0.10 (or later revision) of PPL... yes
checking for installed CLooG PPL Legacy... PPL Legacy
checking for version 0.15.5 (or later revision) of CLooG... yes
*** This configuration is not supported in the following subdirectories:
 gnattools target-libada target-libgfortran target-libffi target-zlib 
target-libjava target-boehm-gc
(Any other directories should still work fine.)
checking for default BUILD_CONFIG... bootstrap-debug
checking for bison... bison -y
checking for bison... bison
checking for gm4... no
checking for gnum4... no
checking for m4... m4
checking for flex... flex
checking for flex... flex
checking for makeinfo... makeinfo
checking for expect... expect
checking for runtest... runtest
checking for ar... ar
checking for as... as
checking for dlltool... no
checking for ld... ld
checking for lipo... no
checking for nm... nm
checking for ranlib... ranlib
checking for strip... strip
checking for windres... no
checking for windmc... no
checking for objcopy... objcopy
checking for objdump... objdump
checking for cc... cc
checking for c++... c++
checking for gcc... gcc
checking for gcj... no
checking for gfortran... no
checking for gccgo... no
checking for ar... no
checking for ar... ar
checking for as... no
checking for as... as
checking for dlltool... no
checking for dlltool... no
checking for ld... no
checking for ld... ld
checking for lipo... no
checking for lipo... no
checking for nm... no
checking for nm... nm
checking for objdump... no
checking for objdump... objdump
checking for ranlib... no
checking for ranlib... ranlib
checking for strip... no
checking for strip... strip
checking for windres... no
checking for windres... no
checking for windmc... no
checking for windmc... no
checking where to find the target ar... host tool
checking where to find the target as... host tool
checking where to find the target cc... just compiled
checking where to find the target c++... 
/usr/src/Lang/gcc-trunk-bstarynk/configure: line 13361: syntax error near 
unexpected token `c++,*'
/usr/src/Lang/gcc-trunk-bstarynk/configure: line 13361: `*, c++,*) 
;;'



Does anyone have an idea of what I am doing wrong? AFAIK, trunk still
requires autoconf 2.64?

Or what is the correct procedure to regenerate a correct ./configure ?


Cheers.
-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: profiledbootstrap fails in java with "error: verification failed at PC=8: branch out of range"

[Andrew Haley]

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:
>>> In method 
>>> 'gnu.java.awt.peer.gtk.GtkComponentPeer.handleEvent(java.awt.AWTEvent)':
>>> In file included from :63:0:
>>> /home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:279:0:
>>> error: verification failed at PC=8: branch out of range
>>> /home/uros/gcc-svn/trunk/libjava/classpath/gnu/java/awt/peer/gtk/GtkComponentPeer.java:279:0:
>>> internal compiler error: Segmentation fault
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See  for instructions.
>>> gmake[5]: *** [gnu-java-awt-peer-gtk.lo] Error 1
>>>
>>> Any info what this verification error means?
>>
>> Either
>>
>> a.  A file (GtkComponentPeer.class) has been corrupted
>>
>> or
>>
>> b.  verify-* in gcc/java has been miscompiled by gcc.
>>
>> or
>>
>> c.  something used by verify-* in gcc/java has changed, and now
>> verify-* is broken.
> 
> Right on spot, It is verify_instructions_0 from verify-impl.c that is
> miscompiled. Following patch avoids these failures and enables
> profiledbootstrap to finish:

Thank you for doing this.

Can I at this point say just how useful Java is in detecting optimization
bugs in gcc?  No?  Ok, I won't then.  :-)

I'll get my coat...

Andrew.

Re: configure related issue: syntax error near unexpected token `c++

[Andreas Schwab]

Basile Starynkevitch  writes:

>  % svn diff 
> Index: configure
> ===
> --- configure (revision 167234)
> +++ configure (working copy)
> @@ -13358,7 +13358,7 @@
>  *) ok=no ;;
>esac
>case ,${enable_languages}, in
> -*,c++,*) ;;
> +*,   c++,*) ;;
>  *) ok=no ;;
>esac
>if test $ok = yes; then

It's a bug in configure.ac.  Installed as obvious.

Andreas.

2010-11-29  Andreas Schwab  

* configure.ac: Move comment to remove extra space in last argument
of GCC_TARGET_TOOL.

Index: configure.ac
===
--- configure.ac(revision 167236)
+++ configure.ac(working copy)
@@ -3235,8 +3235,9 @@
 GCC_TARGET_TOOL(ar, AR_FOR_TARGET, AR, [binutils/ar])
 GCC_TARGET_TOOL(as, AS_FOR_TARGET, AS, [gas/as-new])
 GCC_TARGET_TOOL(cc, CC_FOR_TARGET, CC, [gcc/xgcc -B$$r/$(HOST_SUBDIR)/gcc/])
+dnl see comments for CXX_FOR_TARGET_FLAG_TO_PASS
 GCC_TARGET_TOOL(c++, CXX_FOR_TARGET, CXX,
-   [gcc/g++ -B$$r/$(HOST_SUBDIR)/gcc/ -nostdinc++ `if test -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags; then $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes; 
else echo -funconfigured-libstdc++-v3 ; fi` 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs],dnl see comments for 
CXX_FOR_TARGET_FLAG_TO_PASS
+   [gcc/g++ -B$$r/$(HOST_SUBDIR)/gcc/ -nostdinc++ `if test -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags; then $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes; 
else echo -funconfigured-libstdc++-v3 ; fi` 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs],
c++)
 GCC_TARGET_TOOL(c++ for libstdc++, RAW_CXX_FOR_TARGET, CXX,
[gcc/xgcc -shared-libgcc -B$$r/$(HOST_SUBDIR)/gcc -nostdinc++ 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs],

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Mixing simple & complex IPA passes...?

[Basile Starynkevitch]

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 (pass->type == new_pass_info->pass->type


Why is this test so strong? Why don't we accept SIMPLE_IPA_PASS to be
mixed with IPA_PASS [that is, addimg a plugin-provided SIMPLE_IPA_PASS
after an existing IPA_PASS, etc...]

Why don't we test
 if ((pass->type == new_pass_info->pass->type
 || ((pass->type == IPA_PASS
  || pass->type == SIMPLE_IPA_PASS)
 &&
 (new_pass_info->pass->type == IPA_PASS
  || new_pass_info->pass->type == SIMPLE_IPA_PASS))
instead?

Cheers!

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

best data extraction for SSE2 emulation?

[David Mathog]

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_SINT4(__A)[0] << __B,
EMM_SINT4(__A)[1] << __B,
EMM_SINT4(__A)[2] << __B,
EMM_SINT4(__A)[3] << __B};
  return (__m128i)__tmp;
}

This works fine when testing one _mm function at a time, but does not
work reliably in real programs unless -O0 is used.  I think at least
part of the problem is that once the function is inlined the parameter
__A is in some cases a  register variable, and the pointer method is not
valid there.  To get around that I'm think of introducing an explicit
local variable, like this:

static __inline __m128i __attribute__((__always_inline__))
_mm_slli_epi32 (__m128i __A, int __B)
{
__m128i A = __A;
  __v4si __tmp = {
EMM_SINT4(A)[0] << __B,
EMM_SINT4(A)[1] << __B,
EMM_SINT4(A)[2] << __B,
EMM_SINT4(A)[3] << __B};
  return (__m128i)__tmp;
}

I'm not sure that will work all the time either.  The only other
approach I an aware of would be something like this:

#typedef union {
  __m128i   vi;
  __m128d   vd;
  int   s[4];
  unsigned int  us[4];
  /* etc. for other types */
} emm_universal ;

#define EMM_SINT4(a)   (a).s

static __inline __m128i __attribute__((__always_inline__))
_mm_slli_epi32 (__m128i __A, int __B)
{
emm_universal A;
  A.vi = __A;
 __v4si __tmp = {
EMM_SINT4(A)[0] << __B,
EMM_SINT4(A)[1] << __B,
EMM_SINT4(A)[2] << __B,
EMM_SINT4(A)[3] << __B};
  return (__m128i)__tmp;
}

The union approach seems to be just a different a way to spin the
pointer operations.  For gcc in particular, is one approach or the other
to be preferred and why?

Thanks,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

vector extension bug?

[David Mathog]

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 greatly reduced gccprob2.c:

8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<
#include  /* for printf */
typedef double__m128d __attribute__ ((__vector_size__ (16),
__may_alias__));
typedef union
{
  __m128d x;
  double a[2];
} union128d;
#define EMM_FLT8(a)((double *)&(a))

void test ( __m128d s1, __m128d s2)
{
printf("test s1 %lf %lf\n",EMM_FLT8(s1)[0],EMM_FLT8(s1)[1]);
printf("test s2 %lf %lf\n",EMM_FLT8(s2)[0],EMM_FLT8(s2)[1]);
}

int main (void)
{
__attribute__ ((aligned (16)))  union128d s1;
  s1.a[0] = 1.0;
  s1.a[1] = 2.0;
printf("s1  %lf %lf\n",s1.a[0],s1.a[1]);
  test (s1.x, s1.x);
}
8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<

Test runs:

% gcc -msse -mno-sse2 -m64   -o foo gccprob2.c
% ./foo  #first value in s2 is wrong
s1  1.00 2.00
test s1 1.00 2.00
test s2 2.00 2.00
% gcc -msse -msse2 -m64   -o foo gccprob2.c
% ./foo
s1  1.00 2.00
test s1 1.00 2.00
test s2 1.00 2.00
% gcc -msse -mno-sse2 -lm -m32   -o foo gccprob2.c
% ./foo
s1  1.00 2.00
test s1 1.00 2.00
test s2 1.00 2.00
% gcc --version
gcc (GCC) 4.4.1
% cat /etc/release
Mandriva Linux release 2010.0 (Official) for x86_64
% cat /proc/cpuinfo | head -10 
processor   : 0
vendor_id   : AuthenticAMD
cpu family  : 15
model   : 33
model name  : Dual Core AMD Opteron(tm) Processor 280
stepping: 2
cpu MHz : 1000.000
cache size  : 1024 KB
physical id : 0
siblings: 2

Is there something wrong with this program or is this a compiler bug?

Thanks,

David Mathog
mat...@caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

Re: best data extraction for SSE2 emulation?

[Ian Lance Taylor]

"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 __B)
> {
>   __v4si __tmp = {
> EMM_SINT4(__A)[0] << __B,
> EMM_SINT4(__A)[1] << __B,
> EMM_SINT4(__A)[2] << __B,
> EMM_SINT4(__A)[3] << __B};
>   return (__m128i)__tmp;
> }

You are accessing a value of type __m128i using a pointer of type int*.
That could be an aliasing violation.  Are you using the definition of
__m128i from emmintrin.h, which gives the type the __may_alias__
attribute?


> This works fine when testing one _mm function at a time, but does not
> work reliably in real programs unless -O0 is used.  I think at least
> part of the problem is that once the function is inlined the parameter
> __A is in some cases a  register variable, and the pointer method is not
> valid there.  To get around that I'm think of introducing an explicit
> local variable, like this:
>
> static __inline __m128i __attribute__((__always_inline__))
> _mm_slli_epi32 (__m128i __A, int __B)
> {
> __m128i A = __A;
>   __v4si __tmp = {
> EMM_SINT4(A)[0] << __B,
> EMM_SINT4(A)[1] << __B,
> EMM_SINT4(A)[2] << __B,
> EMM_SINT4(A)[3] << __B};
>   return (__m128i)__tmp;
> }

I can't see why that would make any difference.  You are permitted to
take the address of a parameter.  The compiler will do the right thing.

> I'm not sure that will work all the time either.  The only other
> approach I an aware of would be something like this:
>
> #typedef union {
>   __m128i   vi;
>   __m128d   vd;
>   int   s[4];
>   unsigned int  us[4];
>   /* etc. for other types */
> } emm_universal ;
>
> #define EMM_SINT4(a)   (a).s
>
> static __inline __m128i __attribute__((__always_inline__))
> _mm_slli_epi32 (__m128i __A, int __B)
> {
> emm_universal A;
>   A.vi = __A;
>  __v4si __tmp = {
> EMM_SINT4(A)[0] << __B,
> EMM_SINT4(A)[1] << __B,
> EMM_SINT4(A)[2] << __B,
> EMM_SINT4(A)[3] << __B};
>   return (__m128i)__tmp;
> }
>
> The union approach seems to be just a different a way to spin the
> pointer operations.  For gcc in particular, is one approach or the other
> to be preferred and why?

The advantage of using a union is that there is no aliasing violation.
gcc explicitly permits using a different type to access a value when
using a union.  I would use a union for that reason alone.

Ian

Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Roman Kononov]

$ 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 constexpr requirement should be relaxed
in gnu++0x mode.

Please see the trivial patch.

Thanks
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c	(revision 167200)
+++ gcc/cp/decl.c	(working copy)
@@ -7436,7 +7436,7 @@
  in check_initializer.  */
   if (DECL_P (decl) && DECL_DECLARED_CONSTEXPR_P (decl))
 return 0;
-  else if (cxx_dialect >= cxx0x && !INTEGRAL_OR_ENUMERATION_TYPE_P (type))
+  else if (cxx_dialect >= cxx0x && !INTEGRAL_OR_ENUMERATION_TYPE_P (type) && flag_iso)
 {
   if (literal_type_p (type))
 	error ("% needed for in-class initialization of static "

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Andrew Pinski]

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 existing c++

well this code is not valid C++03 code to begin with.

-- Pinski

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Roman Kononov]

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.

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Marc Glisse]

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

This will break a great deal of existing c++


well this code is not valid C++03 code to begin with.


It is a gcc extension documented here:
http://gcc.gnu.org/onlinedocs/gcc/Deprecated-Features.html

C++0X seems like the right time to drop a deprecated feature, especially 
since an alternative is now available.


--
Marc Glisse

Re: gcc enumeration print support

[Ian Lance Taylor]

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 automatic,
> no need to let programmer print f_unit.ttype and f_unit.index one by
> one.
> gdb print is just like this.
>
> GCC_PRINT(f_unit);=>
> f_unit.ttype = 1
> f_unit.index = 2

This question is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for the development of gcc itself.  It would be appropriate for
gcc-h...@gcc.gnu.org.  Please take any followups to gcc-help.  Thanks.

The answer to your question is no; gcc does not support any such
feature.

Ian

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Gabriel Dos Reis]

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 existing c++ code preventing easy
> transition to c++0x. Maybe, the constexpr requirement should be relaxed
> in gnu++0x mode.
>
> Please see the trivial patch.

I believe you may be confused.

Your program does not use `constexpr' at all, so I think your $SUBJECT and
prognosis is not right.  The above code is invalid C++03 code.  It stays
invalid in C++0x.  However, if you do want to write something like that
in C++0x, you do have to use `constexpr' -- that is what the diagnostic
message is saying.

Summary: this is a non-issue.

-- Gaby

Re: configure related issue: syntax error near unexpected token `c++

[Ian Lance Taylor]

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 can tell
you that it comes from GCC_TARGET_TOOL in the file config/acx.m4 as
invoked by one of these two commands in configure.ac, most likely the
second one.

GCC_TARGET_TOOL(c++, CXX_FOR_TARGET, CXX,
[gcc/g++ -B$$r/$(HOST_SUBDIR)/gcc/ -nostdinc++ `test ! -f 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags || $(SHELL) 
$$r/$(TARGET_SUBDIR)/libstdc++-v3/scripts/testsuite_flags --build-includes` 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs],
c++)
GCC_TARGET_TOOL(c++ for libstdc++, RAW_CXX_FOR_TARGET, CXX,
[gcc/xgcc -shared-libgcc -B$$r/$(HOST_SUBDIR)/gcc -nostdinc++ 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src 
-L$$r/$(TARGET_SUBDIR)/libstdc++-v3/src/.libs],
c++)

I have no explanation for why this isn't working for you.  The
whitespace before the "c++" should be dropped by m4.

Ian

Re: configure related issue: syntax error near unexpected token `c++

[Andreas Schwab]

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 getting this diff.  You should not.

See .

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: vector extension bug?

[Ian Lance Taylor]

"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 with
> -m64 -mno-sse2.  Here is the greatly reduced gccprob2.c:
>
> 8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<
> #include  /* for printf */
> typedef double__m128d __attribute__ ((__vector_size__ (16),
> __may_alias__));
> typedef union
> {
>   __m128d x;
>   double a[2];
> } union128d;
> #define EMM_FLT8(a)((double *)&(a))
>
> void test ( __m128d s1, __m128d s2)
> {
> printf("test s1 %lf %lf\n",EMM_FLT8(s1)[0],EMM_FLT8(s1)[1]);
> printf("test s2 %lf %lf\n",EMM_FLT8(s2)[0],EMM_FLT8(s2)[1]);
> }
>
> int main (void)
> {
> __attribute__ ((aligned (16)))  union128d s1;
>   s1.a[0] = 1.0;
>   s1.a[1] = 2.0;
> printf("s1  %lf %lf\n",s1.a[0],s1.a[1]);
>   test (s1.x, s1.x);
> }
> 8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<8<
>
> Test runs:
>
> % gcc -msse -mno-sse2 -m64   -o foo gccprob2.c
> % ./foo  #first value in s2 is wrong
> s1  1.00 2.00
> test s1 1.00 2.00
> test s2 2.00 2.00
> % gcc -msse -msse2 -m64   -o foo gccprob2.c
> % ./foo
> s1  1.00 2.00
> test s1 1.00 2.00
> test s2 1.00 2.00
> % gcc -msse -mno-sse2 -lm -m32   -o foo gccprob2.c
> % ./foo
> s1  1.00 2.00
> test s1 1.00 2.00
> test s2 1.00 2.00
> % gcc --version
> gcc (GCC) 4.4.1
> % cat /etc/release
> Mandriva Linux release 2010.0 (Official) for x86_64
> % cat /proc/cpuinfo | head -10 
> processor   : 0
> vendor_id   : AuthenticAMD
> cpu family  : 15
> model   : 33
> model name  : Dual Core AMD Opteron(tm) Processor 280
> stepping: 2
> cpu MHz : 1000.000
> cache size  : 1024 KB
> physical id : 0
> siblings: 2
>
> Is there something wrong with this program or is this a compiler bug?


I think this is a compiler bug in the i386 backend.  The
classify_argument function uses X86_64_SSEUP_CLASS for V2DFmode, and
examine_argument counts that as requiring a single SSE register.
However, since the SSE2 instructions are not available, the argument is
split into two SSE registers.  The result is that the first argument is
passed in %xmm0/%xmm1, and the second argument is passed in %xmm1/%xmm2.
That is, the arguments overlap, leading to the incorrect result.

Basically, the 64-bit calling convention support assumes that the SSE2
instructions are always available, and silently fails when -mno-sse2 is
used.  I don't really have an opinion as to whether the compiler needs
to support this case correctly, but I think that clearly it must not
silently fail.

Please consider opening a bug report for this.  Thanks.

Ian

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Ian Lance Taylor]

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
>>
>> This will break a great deal of existing c++ code preventing easy
>> transition to c++0x. Maybe, the constexpr requirement should be relaxed
>> in gnu++0x mode.
>>
>> Please see the trivial patch.
>
> I believe you may be confused.
>
> Your program does not use `constexpr' at all, so I think your $SUBJECT and
> prognosis is not right.  The above code is invalid C++03 code.  It stays
> invalid in C++0x.  However, if you do want to write something like that
> in C++0x, you do have to use `constexpr' -- that is what the diagnostic
> message is saying.
>
> Summary: this is a non-issue.

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 forward to
-std=gnu++0x.  Or we could decide to carry the extension forward to
-std=gnu++0x when -fpermissive is used.  Or we could decide to just drop
the extension.

The main problem with the last option is that it complicates the
migration of existing gnu++98 programs to gnu++0x.  It becomes necessary
to add constexpr to use gnu++0x.  Unfortunately, gnu++98 rejects
constexpr.  So there is no simple way to modify this program to be both
valid gnu++98 and valid gnu++0x.  That makes the transition more
difficult.

It seems to me that it would be better for our users to accept this code
in gnu++0x mode with -fpermissive.

Ian

IRA undoing sched1

[Paul Koning]

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; e=f; g=h;

Sched1, as expected, turns this into four loads followed by four stores, 
exploiting the pipeline.

Then IRA kicks in.  It shuffles the insns back into load/store, load/store 
pairs, essentially the source code order.  It looks like it's doing that to 
reduce the number of registers used.  Fair enough, but this makes the code less 
efficient.  I don't see a way to tell IRA not to do this.

As it happens, there's a secondary reload involved: the loads are into one set 
of registers but the stores from another, so a register to register move is 
added in by reload.  Does that explain the behavior?  I tried changing the 
cover_classes, but that doesn't make a difference.

paul

Re: IRA undoing sched1

[Vladimir Makarov]

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 register.

Test program is basically a=b; c=d; e=f; g=h;

Sched1, as expected, turns this into four loads followed by four stores, 
exploiting the pipeline.

Then IRA kicks in.  It shuffles the insns back into load/store, load/store 
pairs, essentially the source code order.  It looks like it's doing that to 
reduce the number of registers used.  Fair enough, but this makes the code less 
efficient.  I don't see a way to tell IRA not to do this.

Most probably that happens because of ira.c::update_equiv_regs.   This 
function was inherited from the old register allocator.  The major goal 
of the function is to find equivalent memory/constants/invariants for 
pseudos which can be used by reload pass.  Pseudo equivalence also 
affects live range splitting decision in IRA.


Update_equiv_regs can also move insns initiating pseudo equivalences 
close to the pseudo usage.  You could try to prevent this and to see 
what happens.  IMO preventing such insn moving will do more harm on 
performance on SPEC benchmarks for x86/x86-64 processors.

As it happens, there's a secondary reload involved: the loads are into one set 
of registers but the stores from another, so a register to register move is 
added in by reload.  Does that explain the behavior?  I tried changing the 
cover_classes, but that doesn't make a difference.

It is hard to say without the dump file.  If everything is correctly 
defined, it should not happen.

Re: new requirement of "constexpr" for static const float data members is too restrictive

[Miles Bader]

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 forward to
> -std=gnu++0x.  Or we could decide to carry the extension forward to
> -std=gnu++0x when -fpermissive is used.  Or we could decide to just drop
> the extension.
>
> The main problem with the last option is that it complicates the
> migration of existing gnu++98 programs to gnu++0x.  It becomes necessary
> to add constexpr to use gnu++0x.  Unfortunately, gnu++98 rejects
> constexpr.  So there is no simple way to modify this program to be both
> valid gnu++98 and valid gnu++0x.  That makes the transition more
> difficult.
>
> It seems to me that it would be better for our users to accept this code
> in gnu++0x mode with -fpermissive.

I agree.

I used to use this feature a lot, and indeed that was the primary reason
I _didn't_ use -pedantic-errors.

It's nice that C++0x has an official way to support this feature (it
seems very silly that C++98 didn't), but there are surely many projects
that don't want to commit to C++0x just yet.

[Recently I went through and changed all my uses of "static const float"
fields to use inline static methods instead, which is at least portable,
but yuck, how ugly is that...]

BTW, if it's decided that `-fpermissive' should be necessary, I think
the error message should note that ...

-Miles

-- 
Once, adj. Enough.

Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive

[Andrew Pinski]

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 decide to carry the extension forward to
> -std=gnu++0x.  Or we could decide to carry the extension forward to
> -std=gnu++0x when -fpermissive is used.  Or we could decide to just drop
> the extension.
>
> The main problem with the last option is that it complicates the
> migration of existing gnu++98 programs to gnu++0x.  It becomes necessary
> to add constexpr to use gnu++0x.  Unfortunately, gnu++98 rejects
> constexpr.  So there is no simple way to modify this program to be both
> valid gnu++98 and valid gnu++0x.  That makes the transition more
> difficult.
>
> It seems to me that it would be better for our users to accept this code
> in gnu++0x mode with -fpermissive.

Except it is documented as a Deprecated feature already so it is
different from a documented extension.  I would say we should just
drop it as it is documented already as deprecated.

-- Pinski