http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #36 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07
17:21:44 UTC ---
Author: ebotcazou
Date: Tue Feb 7 17:21:36 2012
New Revision: 183974
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183974
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #37 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-07
17:24:32 UTC ---
Author: ebotcazou
Date: Tue Feb 7 17:24:27 2012
New Revision: 183975
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=183975
Log:
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #35 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-06
12:29:06 UTC ---
So your patch is probably ok (can you try verifying we don't get
(too much) codegen differences on a bootstrap?)
There are no differences for a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #34 from rguenther at suse dot de rguenther at suse dot de
2012-02-02 08:56:04 UTC ---
On Wed, 1 Feb 2012, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #32 from Eric Botcazou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #25 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-01
15:34:37 UTC ---
I've changed my mind: given that we shouldn't have references outside the base
object in valid programs, there must be an offset if the bitpos is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #26 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-01
15:36:06 UTC ---
Created attachment 26545
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26545
Tentative fix
Uros, does it fix the original issue?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #28 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-01
15:41:52 UTC ---
(In reply to comment #27)
(In reply to comment #25)
I've changed my mind: given that we shouldn't have references outside the
base
object in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #27 from Richard Guenther rguenth at gcc dot gnu.org 2012-02-01
15:41:15 UTC ---
(In reply to comment #25)
I've changed my mind: given that we shouldn't have references outside the base
object in valid programs, there must be an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Attachment #26545|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #30 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-01
15:53:25 UTC ---
I'm not sure it's the best thing to do (adjusting 'offset' by
a BITS_PER_UNIT multiple instead of whatever the caller would like the most).
Only the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #31 from rguenther at suse dot de rguenther at suse dot de
2012-02-01 16:00:41 UTC ---
On Wed, 1 Feb 2012, ebotcazou at gcc dot gnu.org wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #30 from Eric Botcazou
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #32 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-02-01
16:34:30 UTC ---
The base object can be an indirect reference, so yes, there doesn't have
to be an overall positive offset (well, yes, to the _real_ object,
but we
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #33 from Uros Bizjak ubizjak at gmail dot com 2012-02-01 18:41:59
UTC ---
(In reply to comment #29)
Created attachment 26547 [details]
Correct fix
This adds the missing division...
This patch fixes both the testcase and original
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-26
08:02:50 UTC ---
Doing it in get_inner_reference sounds like a risky change though.
E.g. Richard's PR51750 change would need to be adjusted to match it.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
CC||rguenth at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #19 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-26
10:01:23 UTC ---
I agree, all callers of get_inner_reference need to cope with a negative
bitpos. Those that forward it unchecked to functions that expect an
unsigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #20 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-26
11:00:33 UTC ---
Eric, you should know this area the best - what do you recommend here?
[we could assert in the unsigned bitpos taking functions that the MSB
is not set
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Attachment #26466|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #22 from Uros Bizjak ubizjak at gmail dot com 2012-01-26 18:41:57
UTC ---
(In reply to comment #20)
I agree that making get_inner_reference artificially return a non-zero poffset
would most certainly be problematic as this would
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #23 from Uros Bizjak ubizjak at gmail dot com 2012-01-26 18:51:00
UTC ---
With a crosscompiler to alpha-linux-gnu, we can trigger both problems, one with
preprocessed source, another with the testcase in latest attached patch:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-01-25
11:15:09 UTC ---
Negative bitpos is fine - Ada uses that quite extensively and with MEM_REFs
this just got more prominent. get_inner_reference is declared to return
a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-01-25 11:21:34
UTC ---
Created attachment 26459
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26459
Patch to fix function prototypes
To my surprise, attached patch fixes all git
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #4 from Uros Bizjak ubizjak at gmail dot com 2012-01-25 11:39:11
UTC ---
(In reply to comment #2)
What should happen instead is that store_field needs to adjust the address
to properly point before the bitfield for calling
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-25
12:41:13 UTC ---
(In reply to comment #3)
Created attachment 26459 [details]
Patch to fix function prototypes
To my surprise, attached patch fixes all git failures.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2012-01-25
12:42:14 UTC ---
(In reply to comment #2)
Negative bitpos is fine - Ada uses that quite extensively and with MEM_REFs
this just got more prominent.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2012-01-25 13:19:32
UTC ---
Testcase that crashes on alpha:
--cut here--
extern void abort (void);
char __attribute__((noinline))
test (int a)
{
char buf[] = 0123456789;
char *output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #8 from Uros Bizjak ubizjak at gmail dot com 2012-01-25 13:33:43
UTC ---
And the test in Comment #7 exposed the same problem in extract_bit_field co.
#19 0x005801f4 in extract_bit_field (str_rtx=0x2e85b760,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Attachment #26459|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2012-01-25 14:41:39
UTC ---
(In reply to comment #7)
Testcase that crashes on alpha:
Actually, the test in comment #7 exposed the problem, but was not 100% correct.
This one is:
--cut
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Attachment #26462|0 |1
is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #13 from Uros Bizjak ubizjak at gmail dot com 2012-01-25 18:39:38
UTC ---
Fixing bit position to unsigned in headers is a No-Go. Too many parts of the
compiler depends on unsigned bit positions - we can end with negative subreg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #14 from Uros Bizjak ubizjak at gmail dot com 2012-01-25 19:44:03
UTC ---
(In reply to comment #13)
Perhpaps the return of get_inner_reference can be adjusted to return
equivalent
negative offset expression instead of negative
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org 2012-01-25
20:20:12 UTC ---
Can't most of the callers of get_inner_reference cope with negative bitpos
though? If so, perhaps only the caller or two in the expansion which doesn't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51994
--- Comment #16 from Uros Bizjak ubizjak at gmail dot com 2012-01-26 07:57:10
UTC ---
(In reply to comment #15)
Can't most of the callers of get_inner_reference cope with negative bitpos
though? If so, perhaps only the caller or two in the
39 matches
Mail list logo
