[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Richard Guenther 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #3 from Richard Guenther 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
--- Comment #4 from Andreas Krebbel 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
_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(__beg, __end, __io, __err, __str)
: _M_extract(__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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #5 from Andreas Krebbel 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #6 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Dominique d'Humieres changed: What|Removed |Added CC||dominiq at lps dot ens.fr --- Comment #7 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-09-14 Ever Confirmed|0 |1 --- Comment #8 from Dominique d'Humieres 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 passes7234 # of unexpected failures2 # of expected failures46 # of unsupported tests732 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #9 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Richard Guenther changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #10 from Andreas Krebbel 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Andreas Krebbel changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Andreas Krebbel 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 > > 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 David Edelsohn 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #13 from David Edelsohn 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #14 from Andreas Krebbel 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #15 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #16 from Iain Sandoe 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #17 from Eric Botcazou 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 rsand...@gcc.gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #18 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Oleg Endo changed: What|Removed |Added CC||oleg.e...@t-online.de --- Comment #19 from Oleg Endo 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #20 from Iain Sandoe 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
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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Andreas Krebbel changed: What|Removed |Added Severity|normal |critical
[Bug middle-end/50325] [4.7 Regression] 76 new fails with rev. 177691
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
--- Comment #22 from 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #23 from Iain Sandoe 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #24 from Iain Sandoe 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325
--- Comment #25 from Iain Sandoe 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, 0x1fffdLL, 3.0F};
/* Is layed out thus xx = space directives:
0xfe 0x80 xx xx
0x3F80
0xff fe 80 xx
0x4000
ff ff ff fe 80 xx xx xx
0x4040
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #26 from 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 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #27 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #28 from Eric Botcazou 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Dominique d'Humieres changed: What|Removed |Added Attachment #25270|0 |1 is obsolete|| --- Comment #29 from Dominique d'Humieres 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #30 from David Edelsohn 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #31 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #32 from Eric Botcazou 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #33 from Jakub Jelinek 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #34 from Eric Botcazou 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #35 from Jakub Jelinek 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #36 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 --- Comment #37 from 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 Richard Sandiford 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 rsand...@gcc.gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #38 from 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #39 from Alan Modra 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50325 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #40 from Martin Liška --- commit r10-7151-g82f620e2ba4c440c5e89bb1f73d10a11ed0f2eb4 Author: Eric Botcazou 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.
