[Bug middle-end/50325] New: 76 new fails with rev. 177691

[Bug middle-end/50325] New: 76 new fails with rev. 177691

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

             Bug #: 50325
           Summary: 76 new fails with rev. 177691
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: krebbel@gcc.gnu.org


Author: rguenth
Date: Fri Aug 12 08:55:05 2011
New Revision: 177691

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=177691
Log:
2011-08-12  Richard Guenther  <rguenther@suse.de>

    * call.c (build_over_call): Instead of memcpy use an
    assignment of two MEM_REFs.

Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/call.c

Seem to have introduced a bunch of new fails on s390x:


< LAST_UPDATED: Thu Sep  8 07:27:18 UTC 2011 (revision 177690)
---
> LAST_UPDATED: Thu Sep  8 07:27:15 UTC 2011 (revision 177691)
239c239
< /home/andreas/clean/gcc-head-build/gcc/xgcc  version 4.7.0 20110812
(experimental) [trunk revision 177690] (GCC) 
---
> /home/andreas/patched/gcc-head-build/gcc/xgcc  version 4.7.0 20110812 (experimental) [trunk revision 177691] (GCC) 
245c245,247
< UNRESOLVED: decl_plugin.c compilation, -I.
-I/home/andreas/clean/gcc-head/gcc/testsuite
-I/home/andreas/clean/gcc-head/gcc/testsuite/../../gcc
-I/home/andreas/clean/gcc-head-build/gcc/testsuite/g++/../../../gcc 
-I/home/andreas/clean/gcc-head/gcc/testsuite/../../include
-I/home/andreas/clean/gcc-head/gcc/testsuite/../../libcpp/include  
-I/home/andreas/clean/gcc-head-build/gcc/testsuite/g++/../../../intl  -DIN_GCC
-fPIC -shared
---
> FAIL: g++.dg/tree-ssa/pr41186.C scan-tree-dump fre1 "Replaced b1.D.[0-9]*.i with 0"
> FAIL: g++.dg/tree-ssa/pr41186.C scan-tree-dump fre1 "Replaced b1.D.[0-9]*.f with 1"
> UNRESOLVED: decl_plugin.c compilation, -I. -I/home/andreas/patched/gcc-head/gcc/testsuite -I/home/andreas/patched/gcc-head/gcc/testsuite/../../gcc -I/home/andreas/patched/gcc-head-build/gcc/testsuite/g++/../../../gcc  -I/home/andreas/patched/gcc-head/gcc/testsuite/../../include -I/home/andreas/patched/gcc-head/gcc/testsuite/../../libcpp/include   -I/home/andreas/patched/gcc-head-build/gcc/testsuite/g++/../../../intl  -DIN_GCC -fPIC -shared
251,252c253,254
< # of expected passes          28054
< # of unexpected failures      1
---
> # of expected passes          28052
> # of unexpected failures      3
256c258
< /home/andreas/clean/gcc-head-build/gcc/testsuite/g++/../../g++  version 4.7.0
20110812 (experimental) [trunk revision 177690] (GCC) 
---
> /home/andreas/patched/gcc-head-build/gcc/testsuite/g++/../../g++  version 4.7.0 20110812 (experimental) [trunk revision 177691] (GCC) 
278a281,354
> FAIL: 22_locale/money_get/get/char/13.cc execution test
> FAIL: 22_locale/money_get/get/char/15.cc execution test
> FAIL: 22_locale/money_get/get/char/16.cc execution test
> FAIL: 22_locale/money_get/get/char/17.cc execution test
> FAIL: 22_locale/money_get/get/char/18.cc execution test
> FAIL: 22_locale/money_get/get/char/19.cc execution test
> FAIL: 22_locale/money_get/get/char/38399.cc execution test
> FAIL: 22_locale/money_get/get/char/39168.cc execution test
> FAIL: 22_locale/money_get/get/wchar_t/13.cc execution test
> FAIL: 22_locale/money_get/get/wchar_t/15.cc execution test
> FAIL: 22_locale/money_get/get/wchar_t/16.cc execution test
> FAIL: 22_locale/money_get/get/wchar_t/17.cc execution test
> FAIL: 22_locale/money_get/get/wchar_t/18.cc execution test
> FAIL: 22_locale/money_get/get/wchar_t/19.cc execution test
> FAIL: 22_locale/money_get/get/wchar_t/38399.cc execution test
> FAIL: 22_locale/money_get/get/wchar_t/39168.cc execution test
> FAIL: 22_locale/num_get/get/char/10.cc execution test
> FAIL: 22_locale/num_get/get/char/12.cc execution test
> FAIL: 22_locale/num_get/get/char/15.cc execution test
> FAIL: 22_locale/num_get/get/char/22131.cc execution test
> FAIL: 22_locale/num_get/get/char/39168.cc execution test
> FAIL: 22_locale/num_get/get/char/7.cc execution test
> FAIL: 22_locale/num_get/get/char/9.cc execution test
> FAIL: 22_locale/num_get/get/wchar_t/10.cc execution test
> FAIL: 22_locale/num_get/get/wchar_t/12.cc execution test
> FAIL: 22_locale/num_get/get/wchar_t/15.cc execution test
> FAIL: 22_locale/num_get/get/wchar_t/22131.cc execution test
> FAIL: 22_locale/num_get/get/wchar_t/39168.cc execution test
> FAIL: 22_locale/num_get/get/wchar_t/7.cc execution test
> FAIL: 22_locale/num_get/get/wchar_t/9.cc execution test
> FAIL: 22_locale/time_get/get_date/char/1.cc execution test
> FAIL: 22_locale/time_get/get_date/char/12750.cc execution test
> FAIL: 22_locale/time_get/get_date/char/12791.cc execution test
> FAIL: 22_locale/time_get/get_date/char/2.cc execution test
> FAIL: 22_locale/time_get/get_date/char/26701.cc execution test
> FAIL: 22_locale/time_get/get_date/char/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_date/char/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_date/wchar_t/1.cc execution test
> FAIL: 22_locale/time_get/get_date/wchar_t/12750.cc execution test
> FAIL: 22_locale/time_get/get_date/wchar_t/12791.cc execution test
> FAIL: 22_locale/time_get/get_date/wchar_t/2.cc execution test
> FAIL: 22_locale/time_get/get_date/wchar_t/26701.cc execution test
> FAIL: 22_locale/time_get/get_date/wchar_t/4.cc execution test
> FAIL: 22_locale/time_get/get_date/wchar_t/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_date/wchar_t/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_monthname/char/1.cc execution test
> FAIL: 22_locale/time_get/get_monthname/char/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_monthname/char/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_monthname/wchar_t/1.cc execution test
> FAIL: 22_locale/time_get/get_monthname/wchar_t/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_monthname/wchar_t/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_time/char/1.cc execution test
> FAIL: 22_locale/time_get/get_time/char/2.cc execution test
> FAIL: 22_locale/time_get/get_time/char/4.cc execution test
> FAIL: 22_locale/time_get/get_time/char/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_time/char/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/1.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/2.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/4.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_time/wchar_t/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_weekday/char/1.cc execution test
> FAIL: 22_locale/time_get/get_weekday/char/38081-1.cc execution test
> FAIL: 22_locale/time_get/get_weekday/char/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_weekday/char/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_weekday/wchar_t/1.cc execution test
> FAIL: 22_locale/time_get/get_weekday/wchar_t/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_weekday/wchar_t/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_year/char/1.cc execution test
> FAIL: 22_locale/time_get/get_year/char/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_year/char/wrapped_locale.cc execution test
> FAIL: 22_locale/time_get/get_year/wchar_t/1.cc execution test
> FAIL: 22_locale/time_get/get_year/wchar_t/wrapped_env.cc execution test
> FAIL: 22_locale/time_get/get_year/wchar_t/wrapped_locale.cc execution test
282c358,359
< # of expected passes          8637
---
> # of expected passes          8563
> # of unexpected failures      74
286c363
< Compiler version: 4.7.0 20110812 (experimental) [trunk revision 177690] (GCC) 
---
> Compiler version: 4.7.0 20110812 (experimental) [trunk revision 177691] (GCC) 
288c365
< configure flags: --prefix=/home/andreas/clean/gcc-head-install
--enable-shared --with-system-zlib --enable-threads=posix --enable-__cxa_atexit
--enable-checking --program-suffix=-4.7.0 --enable-languages=c,c++
--enable-decimal-float
---
> configure flags: --prefix=/home/andreas/patched/gcc-head-install --enable-shared --with-system-zlib --enable-threads=posix --enable-__cxa_atexit --enable-checking --program-suffix=-4.7.0 --enable-languages=c,c++ --enable-decimal-float
290c367
< Mail -s "Results for 4.7.0 20110812 (experimental) [trunk revision 177690]
(GCC) testsuite on s390x-ibm-linux-gnu" gcc-testresults@gcc.gnu.org &&
---
> Mail -s "Results for 4.7.0 20110812 (experimental) [trunk revision 177691] (GCC) testsuite on s390x-ibm-linux-gnu" gcc-testresults@gcc.gnu.org &&






13.exe:
/home/andreas/patched/gcc-head/libstdc++-v3/testsuite/22_locale/money_get/get/char/13.cc:53:
void test01(): Assertion `*end01 == '.'' failed.

[Bug middle-end/50325] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-09-08 10:49:08 UTC ---
It looks as a duplicate of pr50137 (with less failures on ppc-darwin).

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
             Blocks|                            |50137
   Target Milestone|---                         |4.7.0
            Summary|76 new fails with rev.      |[4.7 Regression] 76 new
                   |177691                      |fails with rev. 177691

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-08 11:58:54 UTC ---
Supposedly the MEMs get a mode but the alignment isn't that of the mode?
OTOH this is an array of chars:

          array_type = build_array_type (char_type_node,
                                         build_index_type
                                           (size_binop (MINUS_EXPR,
                                                        arg2, size_int (1))));

we should never layout this in a way that array_type gets anything but
BLKmode (well, maybe QImode for size 1).

That said, it really needs some more investigation.  Possible causes must
be similar to those that made us change memcpy -> MEM_REF folding in
fold_builtin_memory_op so many times for STRICT_ALIGNMENT targets.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-09-08 12:10:13 UTC ---
That said, please pick one fail and investigate a bit.  ppc-darwin doesn't
seem to be STRICT_ALIGNMENT.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #4 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-09-14 07:20:14 UTC ---
I've looked into the 22_locale/money_get/get/char/13.cc failure.

The problem is a miscompilation of locale-inst.cc in libstdc++.

Source:

template<typename _CharT, typename _InIter>
    _InIter
    money_get<_CharT, _InIter>::
    do_get(iter_type __beg, iter_type __end, bool __intl, ios_base& __io,
       ios_base::iostate& __err, long double& __units) const
    {
      string __str;
      __beg = __intl ? _M_extract<true>(__beg, __end, __io, __err, __str)
                 : _M_extract<false>(__beg, __end, __io, __err, __str);
      std::__convert_to_v(__str.c_str(), __units, __err, _S_get_c_locale());
      return __beg;
    }

The result of _M_extract is copied into the return ptr field of the
function.  This assignment copies 12 bytes:

MEM[(struct iter_type *)&__beg] = MEM[(struct iter_type *)&D.23511];

expand_assignement expands this using store_field. However
store_bit_field_1 does not seem to handle BLKmode copies correctly for
byte big endian targets if the source cannot exactly be covered by
word mode operands. It calls itself recursively for the last chunk with:

store_bit_field_1 (str_rtx=0x3fff6528a38, bitsize=32, bitnum=64,
bitregion_start=0, bitregion_end=0, 
    fieldmode=DImode, value=0x3fff6528ab0, fallback_p=true)

with value being (subreg:DI (reg:TI 70) 8)

But copying 4 bytes from that value on a big endian target results in
a src value of (subreg:DI (reg:TI 70) 12) so the wrong word is being
copied here.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #5 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-09-14 08:41:21 UTC ---
Created attachment 25270
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25270
Experimental fix

On S/390 all the failures disappear with that patch.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-09-14 12:42:06 UTC ---
> Created attachment 25270 [details]
> Experimental fix

I'll test the patch on ppc-darwin9, but it will take some time on my slow
machine. Meanwhile do you understand why the tests do not fail on
powerpc64-unknown-linux-gnu (see
http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01230.html ) and why there are
"only" 30 failures on darwin?

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dominiq at lps dot ens.fr

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-09-14 18:01:25 UTC ---
*** Bug 50137 has been marked as a duplicate of this bug. ***

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-09-14
     Ever Confirmed|0                           |1

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-09-14 18:03:03 UTC ---
With the patch in comment #5

> Created attachment 25270 [details]
> Experimental fix

and after rebuilding libstdc++-v3 for both -m32 and -m64, the tests with -m64
gives

...
Running target unix/-m64
...
        === libstdc++ Summary ===

# of expected passes        7234
# of unexpected failures    2
# of expected failures        46
# of unsupported tests        732

So the patch fixes pr50137. I'll start a clean bootstrap and a full regtest
tonight (allow for ~36h for the cycle).

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-09-16 14:41:19 UTC ---
I have done a clean bootstrap of powerpc-apple-darwin9 and
x86_64-apple-darwin10 with the patch in comment #5 with all languages except
go. 

I have posted the results of the tests at
http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01559.html
and http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01560.html 
to be compared to the results posted at
http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01360.html
and http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01357.html .

On powerpc-apple-darwin9 all the 22_locale/* failures are fixed without
regression. On x86_64-apple-darwin10 there are two unrelated regressions
(pr50433 and pr50435 that are still there if the patch is reverted).

To be on the safe side it would be nice to do the same tests on
powerpc*-linux-* (and to answer the questions in comment #6;-).

Thanks for the patch.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #10 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-11-16 09:27:59 UTC ---
Author: krebbel
Date: Wed Nov 16 09:27:56 2011
New Revision: 181405

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181405
Log:
2011-11-16  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

    PR middle-end/50325
    * expmed.c (store_bit_field_1): Use extract_bit_field on big
    endian targets if the source cannot be exactly covered by word
    mode chunks.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expmed.c

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Andreas Krebbel <krebbel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #11 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-11-16 09:32:11 UTC ---
(In reply to comment #10)
> Author: krebbel
> Date: Wed Nov 16 09:27:56 2011
> New Revision: 181405
> 
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181405
> Log:
> 2011-11-16  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>
> 
>     PR middle-end/50325
>     * expmed.c (store_bit_field_1): Use extract_bit_field on big
>     endian targets if the source cannot be exactly covered by word
>     mode chunks.
> 
> 
> Modified:
>     trunk/gcc/ChangeLog
>     trunk/gcc/expmed.c

Fixed.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

David Edelsohn <dje at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|s390x-ibm-linux             |s390x-ibm-linux,
                   |                            |powerpc*-*-*
             Status|RESOLVED                    |REOPENED
                 CC|                            |dje at gcc dot gnu.org
               Host|s390x-ibm-linux             |s390x-ibm-linux,
                   |                            |powerpc*-*-*
         Resolution|FIXED                       |
              Build|s390x-ibm-linux             |s390x-ibm-linux,
                   |                            |powerpc*-*-*

--- Comment #12 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-17 13:54:29 UTC ---
The committed patch breaks structs on AIX and Darwin.  AIX and Darwin differ
from PPC64 Linux in the way structs are padded into words.

See
aix.h:#define AGGREGATES_PAD_UPWARD_ALWAYS 1
linux64.h:#define AGGREGATES_PAD_UPWARD_ALWAYS 0

and

darwin_rs6000_special_round_type_align

I suspect that store_bit_field behavior should be honoring those macros and
instead is imposing a single model.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #13 from David Edelsohn <dje at gcc dot gnu.org> 2011-11-17 14:02:47 UTC ---
The comment for the new code show the error in logic:

          /* If the remaining chunk doesn't have full wordsize we have
             to make sure that for big endian machines the higher order
             bits are used.  */

The statement in the comment is not true.  This depends on the target ABI's
aggregate padding rules.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #14 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-11-17 15:23:26 UTC ---
As the tests from Ian Sandoe and Dominique d'Humieres show, the Darwin/AIX
regressions disappear when limiting the extract_bit_field invocation to
fieldmode == BLKmode (as it was in the "Experimental fix" attached to the
bugzilla).

But I'm not sure this is the right fix. In general also the other modes need
correct handling here. If the correct extraction of the source operand really
depends on things like function arg padding the handling in store_bit_field is
doomed to be incomplete.

Richard, could you please have a look!

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #15 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-11-17 16:33:59 UTC ---
> As the tests from Ian Sandoe and Dominique d'Humieres show, the Darwin/AIX
> regressions disappear when limiting the extract_bit_field invocation to
> fieldmode == BLKmode (as it was in the "Experimental fix" attached to the
> bugzilla).

I confirm that revision 181405 breaks the tests in gcc.dg-struct-layout-1/* on
powerpc-apple-darwin9 with -m32 (but not with -m64). These failures are gone if
I revert r181405 and reapply the "Experimental fix" I have tested before.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #16 from Iain Sandoe <iains at gcc dot gnu.org> 2011-11-19 14:56:09 UTC ---
I had a quick look...

actually, I suspect that the BLKmode constraint you originally had is, in fact,
correct.

we are talking about bit fields - i.e contiguous blocks of bits - so, if memory
serves me correctly, we are not in the realm of padding rules  (but I need to
double-check the ABI doc).

so:

When BIG-Endian && !BLKMode ... you are copying the data in reverse order
(pushing the bitfield into the least significant bits of the destination) -
ergo the remaining fragment needs to be stored at the "higher" sub-address of
the fragmented last word.

When BE && BLKmode you are copying in ascending address order (i.e. aligning
the bits to the MS) .. ergo the remaining fragment needs to be copied to the
"lower" sub-address of the last fragmented word.

In saying this, of course, that does not imply that I've checked that the basic
choice is correct.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot
                   |                            |gnu.org

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-11-19 18:38:48 UTC ---
> we are talking about bit fields - i.e contiguous blocks of bits - so, if memory
> serves me correctly, we are not in the realm of padding rules  (but I need to
> double-check the ABI doc).
> 
> so:
> 
> When BIG-Endian && !BLKMode ... you are copying the data in reverse order
> (pushing the bitfield into the least significant bits of the destination) -
> ergo the remaining fragment needs to be stored at the "higher" sub-address of
> the fragmented last word.
> 
> When BE && BLKmode you are copying in ascending address order (i.e. aligning
> the bits to the MS) .. ergo the remaining fragment needs to be copied to the
> "lower" sub-address of the last fragmented word.

In any case, the new code probably needs to be coordinated with this:

      /* Here we transfer the words of the field
     in the order least significant first.
     This is because the most significant word is the one which may
     be less than full.
     However, only do that if the value is not BLKmode.  */

      unsigned int backwards = WORDS_BIG_ENDIAN && fieldmode != BLKmode;

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

rsandifo@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #18 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2011-11-20 10:12:55 UTC ---
Patch also break mips-linux-gnu.  See:

    http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02004.html

(Sorry Eric, overlaps with your comment.  I wrote that based on
what I'd seen yesterday afternoon.)

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[oleg.endo@t-online.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Oleg Endo <oleg.endo@t-online.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |oleg.endo@t-online.de

--- Comment #19 from Oleg Endo <oleg.endo@t-online.de> 2011-11-21 00:48:16 UTC ---
Hello,

the patch from 181405 also breaks things for the SH target when compiling for
big endian.  For instance when compiling the CSiBE set it bails out with:

/home/code/CSiBE/./src/./teem-1.6.0-src/src/air/754.c: In function
'airFPGen_d':
/home/code/CSiBE/./src/./teem-1.6.0-src/src/air/754.c:283:45: internal compiler
error: in int_mode_for_mode, at stor-layout.c:424

I haven't checked the testsuite results, but I guess they are similar to the
other reports.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #20 from Iain Sandoe <iains at gcc dot gnu.org> 2011-11-21 08:08:18 UTC ---
(In reply to comment #18)
> Patch also break mips-linux-gnu.  See:
> 
>     http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02004.html

I applied this on top of r181530 and reg-strapped on powerpc-darwin9.  
The 22_locale tests pass without regression in the struct-layout-1 series.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[davem at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #21 from davem at gcc dot gnu.org 2011-11-21 21:50:46 UTC ---
Author: davem
Date: Mon Nov 21 21:50:41 2011
New Revision: 181598

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=181598
Log:
Revert regression causing changes to store_bit_field_1.

    Revert
    2011-11-16  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>

    PR middle-end/50325
    * expmed.c (store_bit_field_1): Use extract_bit_field on big
    endian targets if the source cannot be exactly covered by word
    mode chunks.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expmed.c

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[krebbel at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Andreas Krebbel <krebbel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #22 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-01 09:22:19 UTC ---
On Thu, 17 Nov 2011, krebbel at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
> 
> --- Comment #14 from Andreas Krebbel <krebbel at gcc dot gnu.org> 2011-11-17 15:23:26 UTC ---
> As the tests from Ian Sandoe and Dominique d'Humieres show, the Darwin/AIX
> regressions disappear when limiting the extract_bit_field invocation to
> fieldmode == BLKmode (as it was in the "Experimental fix" attached to the
> bugzilla).
> 
> But I'm not sure this is the right fix. In general also the other modes need
> correct handling here. If the correct extraction of the source operand really
> depends on things like function arg padding the handling in store_bit_field is
> doomed to be incomplete.
> 
> Richard, could you please have a look!

Well, store_bit_field is supposed to do generic memory fiddling,
dependency on function arg padding is unwanted - and thus such
dependency has to be reflected by argument adjustments in the
caller.

[I can smell some weirdness we might have here though,
but surely latent - if you have such argument (small C testcase
I can look at with a cross?), take its address and perform
aggregate assignment through a pointer - does that still
work?  Thus, does the memory layout of s and q in

foo (struct S s)
{
  struct S q;
}

really differ?

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-01 10:10:10 UTC ---
there is nothing in the ABI doc:

http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/100-32-bit_PowerPC_Function_Calling_Conventions/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438-SW20

that would suggest a different layout of bitfields in the two cases you cite.  

For varargs and K&R style function calls - it can be that double/vect values
end up with a 4 byte alignment on the stack, when they are also passed in regs.
(see PR 34311) - but I doubt that is relevant to this case.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-01 10:25:33 UTC ---
well.. sorry, that might be a bogus comment 
- it depends on whether the following can be interpreted to allow a different
layout on the stack from 'normal' memory.

Since the embedding alignment of bitfields doesn't seem to be specifically
referenced in the struct. layout section (pp10 in the pdf) - other than saying
that it's 'natural' if the first element and 4 bytes otherwise.

but page14 in the pdf of the ABI doc has:

1. All nonvector parameters are aligned on 4-byte boundaries. 
2. Vector parameters are aligned on 16-byte boundaries. 
3. Noncomposite parameters (that is, parameters that are not arrays or data
structures) smaller than 4 bytes 
occupy the high-order bytes of their 4-byte area. 
4. Composite parameters (arrays, structures, and unions) 1 or 2 bytes in size
occupy the low-order bytes 
of their 4-byte area. They are preceded by padding to 4 bytes. 
This rule is inconsistent with other 32-bit PowerPC binary inter faces. In AIX
and Mac OS 9 (and earlier), 
padding bytes always follow the data structure even in the case of composite
parameters smaller than 
4 bytes. 
5. Composite parameters 3 bytes or larger in size occupy the high-order bytes
of their 4-byte area. They 
are followed by padding to make a multiple of 4 bytes, with the padding bytes
being undefined. 

again no specific mention of bitfields ...

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[iains at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #25 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-01 11:08:28 UTC ---
the following tried using the vendor's gcc-4.2:

typedef struct
{
  unsigned short flda:9;
  float b;
  unsigned int fldc:17;
  float d;
  unsigned long long flde:33;
  float f;
} Struct;

extern float __attribute__((noinline)) foo (Struct s);

int main ()
{
  Struct q = {0x1fd, 1.0F, 0x1fffd, 2.0F, 0x1fffffffdLL, 3.0F};

  /* Is layed out thus xx = space directives:
     0xfe 0x80 xx xx
     0x3F800000
     0xff fe 80 xx
     0x40000000
     ff ff ff fe 80 xx xx xx
     0x40400000

     i.e. all ms aligned...
 */

  /* It is passed in r3..r9 in 32 bit chunks with the same organization as
memory
     - no shuffling at that stage.  */
  return (int) foo (q);
}

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #26 from rguenther at suse dot de <rguenther at suse dot de> 2011-12-01 11:23:41 UTC ---
On Thu, 1 Dec 2011, iains at gcc dot gnu.org wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
> 
> --- Comment #23 from Iain Sandoe <iains at gcc dot gnu.org> 2011-12-01 10:10:10 UTC ---
> there is nothing in the ABI doc:
> 
> http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/LowLevelABI/100-32-bit_PowerPC_Function_Calling_Conventions/32bitPowerPC.html#//apple_ref/doc/uid/TP40002438-SW20
> 
> that would suggest a different layout of bitfields in the two cases you cite.  
> 
> For varargs and K&R style function calls - it can be that double/vect values
> end up with a 4 byte alignment on the stack, when they are also passed in regs.
> (see PR 34311) - but I doubt that is relevant to this case.

store_bit_field/extract_bit_field are not about bitfields in the C
sense (despite their names).  They are for setting/extracting a
subset of bits.  Any structure layout issue wrt bitfields has to be
taken into account by the caller (so have any function-argument
layout specialities).

Richard.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #27 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-08 13:00:10 UTC ---
Note that reapplying r181405 with the Richard Sandiford's patch at
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02004.html fixes the failures on
powerpc-apple-darwin9 without visible side effect on x86_64-apple-darwin10.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #28 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-08 17:26:03 UTC ---
> Note that reapplying r181405 with the Richard Sandiford's patch at
> http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02004.html fixes the failures on
> powerpc-apple-darwin9 without visible side effect on x86_64-apple-darwin10.

Then let's do that ASAP.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #25270|0                           |1
        is obsolete|                            |

--- Comment #29 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-01-15 13:31:04 UTC ---
Created attachment 26331
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26331
merged patch

> > Note that reapplying r181405 with the Richard Sandiford's patch at
> > http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02004.html fixes the failures on
> > powerpc-apple-darwin9 without visible side effect on x86_64-apple-darwin10.

I am attaching the resulting patch for revision 183181. Could it be tested on
the platforms for which revision 181405 caused some failures: i.e., AIX
(comment #12, tested without regression on Darwin), mips-linux-gnu (comment
#18), and SH target when compiling for big endian (comment #19).

> Then let's do that ASAP.

Agreed, but I am not a maintainer nor a reviewer!-)

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[dje at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #30 from David Edelsohn <dje at gcc dot gnu.org> 2012-01-16 16:58:14 UTC ---
I tested the attachment patch on AIX.  The results are in the testresults
posted this morning.  No regressions.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #31 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2012-01-16 21:07:50 UTC ---
For the record, I'm still a little uncomfortable with this.
It feels too much like a hack to me.  Eric knows this stuff
much better than I do though, so if he's happy, I'll cede to him.

(In reply to comment #29)
> > > Note that reapplying r181405 with the Richard Sandiford's patch at
> > > http://gcc.gnu.org/ml/gcc-patches/2011-11/msg02004.html fixes the failures on
> > > powerpc-apple-darwin9 without visible side effect on x86_64-apple-darwin10.
> 
> I am attaching the resulting patch for revision 183181. Could it be tested on
> the platforms for which revision 181405 caused some failures: i.e., AIX
> (comment #12, tested without regression on Darwin), mips-linux-gnu (comment
> #18), and SH target when compiling for big endian (comment #19).

It was fine on mips64-linux-gnu (including 32-bit multilibs)
when I tested it originally, so a thumbs up from that point of view.

Richard

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #32 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-16 21:53:42 UTC ---
> For the record, I'm still a little uncomfortable with this.
> It feels too much like a hack to me.  Eric knows this stuff
> much better than I do though, so if he's happy, I'll cede to him.

We have to do something for 4.7 though and I think that the patch is relatively
low risk so I'd go for it.  Let's apply it and see how it fares.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #33 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-16 22:10:16 UTC ---
Please avoid the first hunk in #c29 patch though, it has wrong formatting and
it isn't clear why is that line being changed at all.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[ebotcazou at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #34 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2012-01-16 22:20:52 UTC ---
> Please avoid the first hunk in #c29 patch though, it has wrong formatting and
> it isn't clear why is that line being changed at all.

Yes, this hunk is to be dropped.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #35 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-01-17 11:12:43 UTC ---
So, Richard, are you going to commit it?

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #36 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2012-01-17 11:43:40 UTC ---
(In reply to comment #35)
> So, Richard, are you going to commit it?

I'd prefer it if someone else did TBH.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

--- Comment #37 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2012-01-17 20:37:58 UTC ---
Author: rsandifo
Date: Tue Jan 17 20:37:46 2012
New Revision: 183262

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183262
Log:
gcc/
2012-01-17  Andreas Krebbel  <Andreas.Krebbel@de.ibm.com>
        Richard Sandiford  <rdsandiford@googlemail.com>

    PR middle-end/50325
    PR middle-end/51192
    * optabs.h (simplify_expand_binop): Declare.
    * optabs.c (simplify_expand_binop): Make global.
    * expmed.c (store_bit_field_1): Use simplify_expand_binop on big
    endian targets if the source cannot be exactly covered by word
    mode chunks.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expmed.c
    trunk/gcc/optabs.c
    trunk/gcc/optabs.h

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[rsandifo at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

rsandifo@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #38 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2012-01-17 20:40:22 UTC ---
Patch applied to trunk.

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[amodra at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Alan Modra <amodra at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at gmail dot com

--- Comment #39 from Alan Modra <amodra at gmail dot com> 2012-01-23 09:39:48 UTC ---
*** Bug 51926 has been marked as a duplicate of this bug. ***

[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #40 from Martin Liška <marxin at gcc dot gnu.org> ---
commit r10-7151-g82f620e2ba4c440c5e89bb1f73d10a11ed0f2eb4
Author: Eric Botcazou <ebotcazou@gcc.gnu.org>
Date:   Fri Mar 13 09:16:29 2020 +0100

    Fix unaligned load with small memcpy on the ARM

    store_integral_bit_field is ready to handle BLKmode fields, there is
    even a subtlety with their handling on big-endian targets, see e.g.
    PR middle-end/50325, but not if they are unaligned, so the fix is
    simply to call extract_bit_field for them in order to generate an
    unaligned load.  As a bonus, this subsumes  the big-endian specific
    path that was added under PR middle-end/50325.

            PR middle-end/92071
            * expmed.c (store_integral_bit_field): For fields larger than a
            word, call extract_bit_field on the value if the mode is BLKmode.
            Remove specific path for big-endian targets and tidy things up a
            little bit.