Re: ICE with MEM_REF when Pmode is different from word_mode

[Richard Guenther]

On Wed, May 30, 2012 at 4:31 PM, Mohamed Shafi  wrote:
> On 29 May 2012 17:31, Richard Guenther  wrote:
>> On Tue, May 29, 2012 at 1:57 PM, Mohamed Shafi  wrote:
>>> Hi,
>>>
>>> I am porting a private target in GCC 4.6.3 version. For my target
>>> pointer size is 24bits and word size is 32bits. Moreover a byte is
>>> 32bit
>>>
>>> For the testcase gcc.c-torture/compile/92-1.c i get the following ICE
>>>
>>> 92-1.c: In function 'f':
>>> 92-1.c:18:5: internal compiler error: in size_binop_loc, at
>>> fold-const.c:1436
>>> Please submit a full bug report,
>>> with preprocessed source if appropriate.
>>> See  for instructions
>>>
>>> This is the reduced testcase of the same
>>>
>>>  struct vp {
>>>  int wa;
>>> };
>>>
>>> typedef struct vp *vpt;
>>>
>>> typedef struct vc {
>>>  int o;
>>>  vpt py[8];
>>> } *vct;
>>>
>>> typedef struct np *npt;
>>> struct np {
>>>  vct d;
>>>  int di;
>>> };
>>>
>>> int f(npt dp)
>>> {
>>>  vpt *py;
>>>
>>>  py = &dp->d->py[dp->di];
>>>  return (int)(py[1])->wa;
>>> }
>>>
>>> The ICE happens in tree_slp_vectorizer pass. The following is the tree
>>> dump just before that
>>>
>>> ;; Function f (f)
>>>
>>> f (struct np * dp)
>>> {
>>>  struct vp * D.1232;
>>>  int D.1230;
>>>  unsigned int D.1228;
>>>  int D.1227;
>>>  struct vc * D.1225;
>>>
>>> :
>>>  D.1225_2 = dp_1(D)->d;
>>>  D.1227_4 = dp_1(D)->di;
>>>  D.1228_5 = (unsigned int) D.1227_4;
>>>  D.1232_9 = MEM[(struct vp * *)D.1225_2 + 4B].py[D.1228_5]{lb: 0 sz: 4};
>>>  D.1230_10 = D.1232_9->wa;
>>>  return D.1230_10;
>>> }
>>>
>>> The ICE happens for
>>>
>>>  D.1232_9 = MEM[(struct vp * *)D.1225_2 + 4B].py[D.1228_5]{lb: 0 sz: 4};
>>>
>>> This is due to the addition of the new code in tree-data-ref.c (this
>>> is was not there in 4.5 series)
>>>
>>>  if (TREE_CODE (base) == MEM_REF)
>>>    {
>>>      if (!integer_zerop (TREE_OPERAND (base, 1)))
>>>        {
>>>          if (!poffset)
>>>            {
>>>              double_int moff = mem_ref_offset (base);
>>>              poffset = double_int_to_tree (sizetype, moff);
>>>            }
>>>          else
>>>            poffset = size_binop (PLUS_EXPR, poffset, TREE_OPERAND (base, 
>>> 1));
>>
>> This should use mem_ref_offset, too.
>>
>
> This is present in the trunk also. Will you be submitting a patch for this?

I put it on my TODO list.  Something like

Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 188008)
+++ gcc/tree-data-ref.c (working copy)
@@ -720,13 +720,12 @@ dr_analyze_innermost (struct data_refere
 {
   if (!integer_zerop (TREE_OPERAND (base, 1)))
{
+ double_int moff = mem_ref_offset (base);
+ tree mofft = double_int_to_tree (sizetype, moff);
  if (!poffset)
-   {
- double_int moff = mem_ref_offset (base);
- poffset = double_int_to_tree (sizetype, moff);
-   }
+   poffset = mofft;
  else
-   poffset = size_binop (PLUS_EXPR, poffset, TREE_OPERAND (base, 1));
+   poffset = size_binop (PLUS_EXPR, poffset, mofft);
}
   base = TREE_OPERAND (base, 0);
 }


> Shafi

Distributing 'make check' across a cluster

[Diego Novillo]

Ben, we briefly chatted about this earlier.  Here's more details.

I'm trying to distribute GCC testing across nodes in a cluster that do 
not share a common file system.  The strategy is (roughly) to avoid 
using the build tree and distribute:


1- The installed tree out of 'make install'.

2- All the files in /testsuite/lib/

3- All the files in /testsuite/config/

4- A complete testsuite directory (say gcc/testsuite/g++.dg/tree-ssa) 
together with its closest .exp driver file (in this case ../dg.exp).


5- On the machine receiving that directory, create a site.exp defining 
things like srcdir, tmpdir, G*_UNDER_TEST and execute 'runtest'.


This is working pretty well for everything outside of libstdc++.  I can 
reduce testing from about an hour to a few minutes (we test -m32 and -m64).


libstdc++ seems to be doing a few other manipulations of site.exp and 
additional setup that's defeating my scripts.  Any pointers to where I 
should be looking?


If I can get this to work, it would be entirely possible to set it up on 
the FSF farm (provided the distribution overhead is tolerable).



Thanks.  Diego.

Re: Distributing 'make check' across a cluster

[Joseph S. Myers]

On Thu, 31 May 2012, Diego Novillo wrote:

> This is working pretty well for everything outside of libstdc++.  I can reduce
> testing from about an hour to a few minutes (we test -m32 and -m64).
> 
> libstdc++ seems to be doing a few other manipulations of site.exp and
> additional setup that's defeating my scripts.  Any pointers to where I should
> be looking?

libstdc++ definitely works with installed testing (there may be a bug or 
two, e.g. PR 23867, that mean a few tests don't get run that way); it's 
how Mentor's testing works.

That is however installed testing with a complete source tree available 
(but not a build tree); I don't know exactly what is needed from outside 
the testsuite/ directory (but see 
libstdc++-v3/testsuite/lib/libstdc++.exp:libstdc++_init for what happens 
during the testsuite setup).

C, C++, Fortran, Obj-C and Obj-C++ testing have been known to work in the 
past for installed testing.  Java, Ada and Go are quite likely to have 
problems; I don't think I've tried installed testing for libmudflap, 
libffi, libitm, libatomic (but it should work for libgomp).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Distributing 'make check' across a cluster

[Diego Novillo]

On 12-05-31 10:28 , Joseph S. Myers wrote:


libstdc++ definitely works with installed testing (there may be a bug or
two, e.g. PR 23867, that mean a few tests don't get run that way); it's
how Mentor's testing works.


Great.


That is however installed testing with a complete source tree available
(but not a build tree); I don't know exactly what is needed from outside
the testsuite/ directory (but see
libstdc++-v3/testsuite/lib/libstdc++.exp:libstdc++_init for what happens
during the testsuite setup).


Thanks.  Having the source tree available is not a problem, as I require 
it to copy the actual testsuites into the work tree.  Adding a few more 
files from the source tree would not be a problem.



C, C++, Fortran, Obj-C and Obj-C++ testing have been known to work in the
past for installed testing.  Java, Ada and Go are quite likely to have
problems; I don't think I've tried installed testing for libmudflap,
libffi, libitm, libatomic (but it should work for libgomp).


Yeah, right now I'm concentrating on the main C, C++ and Fortran tests. 
 Once I have the basic harness ready, I will look at the other languages.



Thanks.  Diego.

backporting PR52558 to 4.7?

[Aldy Hernandez]

Hello gentlemen.

Would it be ok to backport the fix for PR52558 into the 4.7 branch? 
This PR is the store data race patch I have been iterating with Richi. 
Doing so will avoid critical data races for both TM and the C++ memory 
model.


The code is all predicated by flag_tm or !PARAM_VALUE 
(PARAM_ALLOW_STORE_DATA_RACES)), so it shouldn't affect code paths 
outside of TM or the C++1x memory model.


Thanks.
Aldy

Re: C++98/C++11 ABI compatibility for gcc-4.7

[James Y Knight]

You've missed at least one ABI incompatibility in GCC 4.7 and later, as
demonstrated in real life by (at least) libboost_python, and distilled
into this test case.

At least these bug reports are probably caused by this ABI incompatibility:
https://svn.boost.org/trac/boost/ticket/6919
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
https://svn.boost.org/trac/boost/ticket/6895

As I've said before, I really wish GCC devs would take the ABI
incompatibility problem more seriously. Lots of users have already started
using -std=c++0x mode, and have absolutely no idea that it's completely
unsafe to do so on a normal linux distro, linking against regular C++
libraries that are not compiled with a) c++11 enabled, and b) the exact
same version of GCC.

I understand that the ABI changes generally cannot be avoided, but a lot
of pain for a lot of people could be avoided by making things fail
obviously with a link error, instead of sometimes, arbitrarily, if you're
lucky, you'll get a segfault at runtime.

test1.cpp
#include 

std::pair execute()
{
return std::make_pair(0, 1);
}

test2.cpp
#include 
#include 

std::pair execute();

int main() {
std::pair result = execute();
printf("%d %d\n", result.first, result.second);
}

test.sh
#!/bin/sh
CC="g++-4.7 -O1"
$CC -std=c++03 -o test_cxx03.o -c test.cpp
$CC -std=c++0x -o test_cxx11.o -c test.cpp
$CC -std=c++03 -o test2_cxx03.o -c test2.cpp
$CC -std=c++0x -o test2_cxx11.o -c test2.cpp

$CC -o test test_cxx03.o test2_cxx03.o; ./test
$CC -o test test_cxx11.o test2_cxx11.o; ./test
$CC -o test test_cxx03.o test2_cxx11.o; ./test
$CC -o test test_cxx11.o test2_cxx03.o; ./test

output

0 1
0 1
-1757034448 32767
Segmentation fault

Re: C++98/C++11 ABI compatibility for gcc-4.7

[Jonathan Wakely]

On 31 May 2012 22:35, James Y Knight wrote:
> You've missed at least one ABI incompatibility in GCC 4.7 and later, as
> demonstrated in real life by (at least) libboost_python, and distilled
> into this test case.
>
> At least these bug reports are probably caused by this ABI incompatibility:
> https://svn.boost.org/trac/boost/ticket/6919
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53455
> https://svn.boost.org/trac/boost/ticket/6895
>
> As I've said before, I really wish GCC devs would take the ABI
> incompatibility problem more seriously.

What do you expect us to do, not implement C++11?

> Lots of users have already started
> using -std=c++0x mode, and have absolutely no idea that it's completely
> unsafe to do so on a normal linux distro, linking against regular C++
> libraries that are not compiled with a) c++11 enabled, and b) the exact
> same version of GCC.
>
> I understand that the ABI changes generally cannot be avoided, but a lot
> of pain for a lot of people could be avoided by making things fail
> obviously with a link error, instead of sometimes, arbitrarily, if you're
> lucky, you'll get a segfault at runtime.

Do you have any suggestions for how to do that?

Have you opened an enhancement request in Bugzilla?

Re: C++98/C++11 ABI compatibility for gcc-4.7

[Jonathan Wakely]

On 31 May 2012 22:39, Jonathan Wakely wrote:
> On 31 May 2012 22:35, James Y Knight wrote:
>> I understand that the ABI changes generally cannot be avoided, but a lot
>> of pain for a lot of people could be avoided by making things fail
>> obviously with a link error, instead of sometimes, arbitrarily, if you're
>> lucky, you'll get a segfault at runtime.
>
> Do you have any suggestions for how to do that?

... *without* breaking the current ABI, because if we weren't trying
to keep it stable it would be much easier.

If you want to you can configure with
--enable-symvers=gnu-versioned-namespace and test that mode, which
would allow everything to be put in something like std::__cxx2011::__8
for -std=c++11 mode, but AFAICT only one person seems to be trying
that option out and giving feedback on it.

Re: C++98/C++11 ABI compatibility for gcc-4.7

[James Y Knight]

> On 31 May 2012 22:35, James Y Knight wrote:
>> I understand that the ABI changes generally cannot be avoided, but a lot
>> of pain for a lot of people could be avoided by making things fail
>> obviously with a link error, instead of sometimes, arbitrarily, if
>> you're
>> lucky, you'll get a segfault at runtime.
>
> Do you have any suggestions for how to do that?

Sure, I have a suggestion. I'm not an expert here, so perhaps it has
issues, but...here goes anyways.

Inline namespaces could be used in C++11 mode. libstdc++ would include two
copies of all affected objects: one compiled in C++03 mode with the C++03
names, and one compiled in C++11 mode with the C++11 names. Classes should
be given a new name every time they change incompatibly in C++11 mode,
which is probably every release for a number of classes.

For the C++11-specific symbols that'd be exported from libstdc++ when
doing this, you'd have to decide whether to let them appear and disappear
every GCC release without a pretense of backward compatibility (c++11 mode
being experimental, after all), or, to preserve enough of the old class
definitions internally to the library that the old symbols with the old
behavior can continue being exported, even when the classes have been
modified (nicer for users, but harder on implementors).



Also helpful, even before a technical solution has been created, would be
for the incompatibility to mentioned prominently in the GCC manual when
describing the -std=c++0x/11 option, and in big letters on
http://gcc.gnu.org/projects/cxx0x.html.

As I said, pretty much nobody even knows that this is a problem, unless
they follow the GCC mailing lists or until they run into it independently
and figure out what's happened. Since GCC 4.7 implements a fair portion of
C++11, and C++11 is starting to gain a lot of traction, I'd expect these
issues to start coming up more and more frequently, as more and more
people start compiling their programs in C++11 mode.

gcc-4.5-20120531 is now available

[gccadmin]

Snapshot gcc-4.5-20120531 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120531/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch 
revision 188083

You'll find:

 gcc-4.5-20120531.tar.bz2 Complete GCC

  MD5=4091f4272078449d61310a78f6bf4506
  SHA1=b248a54efa25cdd1f5d371c374404aaad238940a

Diffs from 4.5-20120524 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Distributing 'make check' across a cluster

[Benjamin Kosnik]

> Thanks.  Having the source tree available is not a problem, as I
> require it to copy the actual testsuites into the work tree.  Adding
> a few more files from the source tree would not be a problem.

From:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html

You can run the tests with a compiler and library that have already
been installed. Make sure that the compiler (e.g., g++) is in your
PATH. If you are using shared libraries, then you must also ensure that
the directory containing the shared version of libstdc++ is in your
LD_LIBRARY_PATH, or equivalent. If your GCC source tree is
at /path/to/gcc, then you can run the tests as follows:

runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite


Anyway. I don't test this way often, so all I know is that it used to
work. If you have problems let me know and I'll fix 'em.

 -benjamin

Re: Distributing 'make check' across a cluster

[Jeff Law]

On 05/31/2012 05:22 PM, Benjamin Kosnik wrote:



Thanks.  Having the source tree available is not a problem, as I
require it to copy the actual testsuites into the work tree.  Adding
a few more files from the source tree would not be a problem.


From:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/test.html

You can run the tests with a compiler and library that have already
been installed. Make sure that the compiler (e.g., g++) is in your
PATH. If you are using shared libraries, then you must also ensure that
the directory containing the shared version of libstdc++ is in your
LD_LIBRARY_PATH, or equivalent. If your GCC source tree is
at /path/to/gcc, then you can run the tests as follows:

runtest --tool libstdc++ --srcdir=/path/to/gcc/libstdc++-v3/testsuite


Anyway. I don't test this way often, so all I know is that it used to
work. If you have problems let me know and I'll fix 'em.
I think this still works -- AFAIK Red Hat's QE team makes use of this 
capability.


Jeff