* [Bug middle-end/50325] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
@ 2011-09-08 10:51 ` dominiq at lps dot ens.fr
2011-09-08 12:10 ` [Bug middle-end/50325] [4.7 Regression] " rguenth at gcc dot gnu.org
` (40 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-09-08 10:51 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
2011-09-08 10:51 ` [Bug middle-end/50325] " dominiq at lps dot ens.fr
@ 2011-09-08 12:10 ` rguenth at gcc dot gnu.org
2011-09-08 12:35 ` rguenth at gcc dot gnu.org
` (39 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-09-08 12:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
2011-09-08 10:51 ` [Bug middle-end/50325] " dominiq at lps dot ens.fr
2011-09-08 12:10 ` [Bug middle-end/50325] [4.7 Regression] " rguenth at gcc dot gnu.org
@ 2011-09-08 12:35 ` rguenth at gcc dot gnu.org
2011-09-14 7:38 ` krebbel at gcc dot gnu.org
` (38 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-09-08 12:35 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (2 preceding siblings ...)
2011-09-08 12:35 ` rguenth at gcc dot gnu.org
@ 2011-09-14 7:38 ` krebbel at gcc dot gnu.org
2011-09-14 8:50 ` krebbel at gcc dot gnu.org
` (37 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: krebbel at gcc dot gnu.org @ 2011-09-14 7:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (3 preceding siblings ...)
2011-09-14 7:38 ` krebbel at gcc dot gnu.org
@ 2011-09-14 8:50 ` krebbel at gcc dot gnu.org
2011-09-14 13:33 ` dominiq at lps dot ens.fr
` (36 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: krebbel at gcc dot gnu.org @ 2011-09-14 8:50 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (4 preceding siblings ...)
2011-09-14 8:50 ` krebbel at gcc dot gnu.org
@ 2011-09-14 13:33 ` dominiq at lps dot ens.fr
2011-09-14 18:04 ` dominiq at lps dot ens.fr
` (35 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-09-14 13:33 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (5 preceding siblings ...)
2011-09-14 13:33 ` dominiq at lps dot ens.fr
@ 2011-09-14 18:04 ` dominiq at lps dot ens.fr
2011-09-14 18:29 ` dominiq at lps dot ens.fr
` (34 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-09-14 18:04 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (6 preceding siblings ...)
2011-09-14 18:04 ` dominiq at lps dot ens.fr
@ 2011-09-14 18:29 ` dominiq at lps dot ens.fr
2011-09-16 14:46 ` dominiq at lps dot ens.fr
` (33 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-09-14 18:29 UTC (permalink / raw)
To: gcc-bugs
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).
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (7 preceding siblings ...)
2011-09-14 18:29 ` dominiq at lps dot ens.fr
@ 2011-09-16 14:46 ` dominiq at lps dot ens.fr
2011-10-10 12:36 ` rguenth at gcc dot gnu.org
` (32 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-09-16 14:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (8 preceding siblings ...)
2011-09-16 14:46 ` dominiq at lps dot ens.fr
@ 2011-10-10 12:36 ` rguenth at gcc dot gnu.org
2011-11-16 9:50 ` krebbel at gcc dot gnu.org
` (31 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rguenth at gcc dot gnu.org @ 2011-10-10 12:36 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (9 preceding siblings ...)
2011-10-10 12:36 ` rguenth at gcc dot gnu.org
@ 2011-11-16 9:50 ` krebbel at gcc dot gnu.org
2011-11-16 10:22 ` krebbel at gcc dot gnu.org
` (30 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: krebbel at gcc dot gnu.org @ 2011-11-16 9:50 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (10 preceding siblings ...)
2011-11-16 9:50 ` krebbel at gcc dot gnu.org
@ 2011-11-16 10:22 ` krebbel at gcc dot gnu.org
2011-11-17 15:19 ` dje at gcc dot gnu.org
` (29 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: krebbel at gcc dot gnu.org @ 2011-11-16 10:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (11 preceding siblings ...)
2011-11-16 10:22 ` krebbel at gcc dot gnu.org
@ 2011-11-17 15:19 ` dje at gcc dot gnu.org
2011-11-17 15:21 ` dje at gcc dot gnu.org
` (28 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dje at gcc dot gnu.org @ 2011-11-17 15:19 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (12 preceding siblings ...)
2011-11-17 15:19 ` dje at gcc dot gnu.org
@ 2011-11-17 15:21 ` dje at gcc dot gnu.org
2011-11-17 15:53 ` krebbel at gcc dot gnu.org
` (27 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dje at gcc dot gnu.org @ 2011-11-17 15:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (13 preceding siblings ...)
2011-11-17 15:21 ` dje at gcc dot gnu.org
@ 2011-11-17 15:53 ` krebbel at gcc dot gnu.org
2011-11-17 16:38 ` dominiq at lps dot ens.fr
` (26 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: krebbel at gcc dot gnu.org @ 2011-11-17 15:53 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (14 preceding siblings ...)
2011-11-17 15:53 ` krebbel at gcc dot gnu.org
@ 2011-11-17 16:38 ` dominiq at lps dot ens.fr
2011-11-19 16:08 ` iains at gcc dot gnu.org
` (25 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-11-17 16:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (15 preceding siblings ...)
2011-11-17 16:38 ` dominiq at lps dot ens.fr
@ 2011-11-19 16:08 ` iains at gcc dot gnu.org
2011-11-19 19:29 ` ebotcazou at gcc dot gnu.org
` (24 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: iains at gcc dot gnu.org @ 2011-11-19 16:08 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (16 preceding siblings ...)
2011-11-19 16:08 ` iains at gcc dot gnu.org
@ 2011-11-19 19:29 ` ebotcazou at gcc dot gnu.org
2011-11-20 12:32 ` rsandifo at gcc dot gnu.org
` (23 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2011-11-19 19:29 UTC (permalink / raw)
To: gcc-bugs
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;
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (17 preceding siblings ...)
2011-11-19 19:29 ` ebotcazou at gcc dot gnu.org
@ 2011-11-20 12:32 ` rsandifo at gcc dot gnu.org
2011-11-21 0:55 ` oleg.endo@t-online.de
` (22 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2011-11-20 12:32 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (18 preceding siblings ...)
2011-11-20 12:32 ` rsandifo at gcc dot gnu.org
@ 2011-11-21 0:55 ` oleg.endo@t-online.de
2011-11-21 8:42 ` iains at gcc dot gnu.org
` (21 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: oleg.endo@t-online.de @ 2011-11-21 0:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (19 preceding siblings ...)
2011-11-21 0:55 ` oleg.endo@t-online.de
@ 2011-11-21 8:42 ` iains at gcc dot gnu.org
2011-11-21 22:03 ` davem at gcc dot gnu.org
` (20 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: iains at gcc dot gnu.org @ 2011-11-21 8:42 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (20 preceding siblings ...)
2011-11-21 8:42 ` iains at gcc dot gnu.org
@ 2011-11-21 22:03 ` davem at gcc dot gnu.org
2011-11-22 9:49 ` krebbel at gcc dot gnu.org
` (19 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: davem at gcc dot gnu.org @ 2011-11-21 22:03 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (21 preceding siblings ...)
2011-11-21 22:03 ` davem at gcc dot gnu.org
@ 2011-11-22 9:49 ` krebbel at gcc dot gnu.org
2011-12-01 9:22 ` rguenther at suse dot de
` (18 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: krebbel at gcc dot gnu.org @ 2011-11-22 9:49 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (22 preceding siblings ...)
2011-11-22 9:49 ` krebbel at gcc dot gnu.org
@ 2011-12-01 9:22 ` rguenther at suse dot de
2011-12-01 10:11 ` iains at gcc dot gnu.org
` (17 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rguenther at suse dot de @ 2011-12-01 9:22 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (23 preceding siblings ...)
2011-12-01 9:22 ` rguenther at suse dot de
@ 2011-12-01 10:11 ` iains at gcc dot gnu.org
2011-12-01 10:26 ` iains at gcc dot gnu.org
` (16 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: iains at gcc dot gnu.org @ 2011-12-01 10:11 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (24 preceding siblings ...)
2011-12-01 10:11 ` iains at gcc dot gnu.org
@ 2011-12-01 10:26 ` iains at gcc dot gnu.org
2011-12-01 11:08 ` iains at gcc dot gnu.org
` (15 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: iains at gcc dot gnu.org @ 2011-12-01 10:26 UTC (permalink / raw)
To: gcc-bugs
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 ...
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (25 preceding siblings ...)
2011-12-01 10:26 ` iains at gcc dot gnu.org
@ 2011-12-01 11:08 ` iains at gcc dot gnu.org
2011-12-01 11:26 ` rguenther at suse dot de
` (14 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: iains at gcc dot gnu.org @ 2011-12-01 11:08 UTC (permalink / raw)
To: gcc-bugs
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);
}
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (26 preceding siblings ...)
2011-12-01 11:08 ` iains at gcc dot gnu.org
@ 2011-12-01 11:26 ` rguenther at suse dot de
2012-01-08 13:00 ` dominiq at lps dot ens.fr
` (13 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rguenther at suse dot de @ 2011-12-01 11:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (27 preceding siblings ...)
2011-12-01 11:26 ` rguenther at suse dot de
@ 2012-01-08 13:00 ` dominiq at lps dot ens.fr
2012-01-08 17:26 ` ebotcazou at gcc dot gnu.org
` (12 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-01-08 13:00 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (28 preceding siblings ...)
2012-01-08 13:00 ` dominiq at lps dot ens.fr
@ 2012-01-08 17:26 ` ebotcazou at gcc dot gnu.org
2012-01-15 13:40 ` dominiq at lps dot ens.fr
` (11 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2012-01-08 17:26 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (29 preceding siblings ...)
2012-01-08 17:26 ` ebotcazou at gcc dot gnu.org
@ 2012-01-15 13:40 ` dominiq at lps dot ens.fr
2012-01-16 17:06 ` dje at gcc dot gnu.org
` (10 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dominiq at lps dot ens.fr @ 2012-01-15 13:40 UTC (permalink / raw)
To: gcc-bugs
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!-)
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (30 preceding siblings ...)
2012-01-15 13:40 ` dominiq at lps dot ens.fr
@ 2012-01-16 17:06 ` dje at gcc dot gnu.org
2012-01-16 21:32 ` rsandifo at gcc dot gnu.org
` (9 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: dje at gcc dot gnu.org @ 2012-01-16 17:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (31 preceding siblings ...)
2012-01-16 17:06 ` dje at gcc dot gnu.org
@ 2012-01-16 21:32 ` rsandifo at gcc dot gnu.org
2012-01-16 22:05 ` ebotcazou at gcc dot gnu.org
` (8 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2012-01-16 21:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (32 preceding siblings ...)
2012-01-16 21:32 ` rsandifo at gcc dot gnu.org
@ 2012-01-16 22:05 ` ebotcazou at gcc dot gnu.org
2012-01-16 22:21 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2012-01-16 22:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (33 preceding siblings ...)
2012-01-16 22:05 ` ebotcazou at gcc dot gnu.org
@ 2012-01-16 22:21 ` jakub at gcc dot gnu.org
2012-01-16 23:06 ` ebotcazou at gcc dot gnu.org
` (6 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-01-16 22:21 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (34 preceding siblings ...)
2012-01-16 22:21 ` jakub at gcc dot gnu.org
@ 2012-01-16 23:06 ` ebotcazou at gcc dot gnu.org
2012-01-17 11:36 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: ebotcazou at gcc dot gnu.org @ 2012-01-16 23:06 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (35 preceding siblings ...)
2012-01-16 23:06 ` ebotcazou at gcc dot gnu.org
@ 2012-01-17 11:36 ` jakub at gcc dot gnu.org
2012-01-17 12:09 ` rsandifo at gcc dot gnu.org
` (4 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: jakub at gcc dot gnu.org @ 2012-01-17 11:36 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (36 preceding siblings ...)
2012-01-17 11:36 ` jakub at gcc dot gnu.org
@ 2012-01-17 12:09 ` rsandifo at gcc dot gnu.org
2012-01-17 22:10 ` rsandifo at gcc dot gnu.org
` (3 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2012-01-17 12:09 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (37 preceding siblings ...)
2012-01-17 12:09 ` rsandifo at gcc dot gnu.org
@ 2012-01-17 22:10 ` rsandifo at gcc dot gnu.org
2012-01-17 23:46 ` rsandifo at gcc dot gnu.org
` (2 subsequent siblings)
41 siblings, 0 replies; 43+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2012-01-17 22:10 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (38 preceding siblings ...)
2012-01-17 22:10 ` rsandifo at gcc dot gnu.org
@ 2012-01-17 23:46 ` rsandifo at gcc dot gnu.org
2012-01-23 10:12 ` amodra at gmail dot com
2020-03-13 9:10 ` marxin at gcc dot gnu.org
41 siblings, 0 replies; 43+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2012-01-17 23:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (39 preceding siblings ...)
2012-01-17 23:46 ` rsandifo at gcc dot gnu.org
@ 2012-01-23 10:12 ` amodra at gmail dot com
2020-03-13 9:10 ` marxin at gcc dot gnu.org
41 siblings, 0 replies; 43+ messages in thread
From: amodra at gmail dot com @ 2012-01-23 10:12 UTC (permalink / raw)
To: gcc-bugs
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. ***
^ permalink raw reply [flat|nested] 43+ messages in thread* [Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
2011-09-08 10:32 [Bug middle-end/50325] New: 76 new fails with rev. 177691 krebbel at gcc dot gnu.org
` (40 preceding siblings ...)
2012-01-23 10:12 ` amodra at gmail dot com
@ 2020-03-13 9:10 ` marxin at gcc dot gnu.org
41 siblings, 0 replies; 43+ messages in thread
From: marxin at gcc dot gnu.org @ 2020-03-13 9:10 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 43+ messages in thread