On Nov 6, 2015, at 5:06 AM, Richard Biener wrote:
>> If there are no substantial reasons to not check it in now, I’d like to
>> proceed and get it checked in. People can refine it further in tree if they
>> want. Any objections?
>
> Ok with a changelog entry and bootstrap/regtest.
Also commi
On Fri, Nov 6, 2015 at 2:34 AM, Mike Stump wrote:
> On Nov 5, 2015, at 4:32 AM, Richard Biener wrote:
>> No idea on location lists but maybe this means we should just use the
>> maximum supported integer mode for CONST_WIDE_INTs?
>
> Ah, yeah, that sounds like a fine idea. Below is that version.
On Nov 5, 2015, at 4:32 AM, Richard Biener wrote:
> No idea on location lists but maybe this means we should just use the
> maximum supported integer mode for CONST_WIDE_INTs?
Ah, yeah, that sounds like a fine idea. Below is that version. I snuck in one
more change, as it was annoying me, and
On Thu, Nov 5, 2015 at 12:45 AM, Mike Stump wrote:
>
> On Nov 4, 2015, at 12:50 PM, Richard Sandiford
> wrote:
>
>> Mike Stump writes:
>>> Index: dwarf2out.c
>>> ===
>>> --- dwarf2out.c (revision 229720)
>>> +++ dwarf2out.c
On Nov 4, 2015, at 12:50 PM, Richard Sandiford
wrote:
> Mike Stump writes:
>> Index: dwarf2out.c
>> ===
>> --- dwarf2out.c (revision 229720)
>> +++ dwarf2out.c (working copy)
>> @@ -15593,8 +15593,13 @@
>> return t
Mike Stump writes:
> Index: dwarf2out.c
> ===
> --- dwarf2out.c (revision 229720)
> +++ dwarf2out.c (working copy)
> @@ -15593,8 +15593,13 @@
>return true;
>
> case CONST_WIDE_INT:
> - add_AT_wide (die,
On Nov 4, 2015, at 4:15 AM, Richard Biener wrote:
> I wonder if we'll manage to to get mode_for_size return BLKmode
> in case of an original mode that was not of a size multiple of
> HOST_BITS_PER_WIDE_INT (and that's host dependent even…).
> We probably should use smallest_mode_for_size on a pre
On Wed, Nov 4, 2015 at 12:57 PM, Mike Stump wrote:
> On Nov 4, 2015, at 1:43 AM, Richard Biener wrote:
>> I think you should limit the effect of this patch to the dwarf2out use
>> as the above doesn't make sense to me.
>
> Since dwarf is so special, and since other clients already do something so
On Nov 4, 2015, at 1:43 AM, Richard Biener wrote:
> I think you should limit the effect of this patch to the dwarf2out use
> as the above doesn't make sense to me.
Since dwarf is so special, and since other clients already do something sort of
like this anyway, it isn’t unreasonable to make the
On Tue, Nov 3, 2015 at 10:58 PM, Mike Stump wrote:
> On Nov 3, 2015, at 12:46 AM, Richard Sandiford
> wrote:
>> This isn't just an argument about the DWARF standard though. It's an
>> argument about GCC internals. Presumably these hypothetical BLKmode
>> types would need to support addition,
>
On Nov 3, 2015, at 12:46 AM, Richard Sandiford
wrote:
> This isn't just an argument about the DWARF standard though. It's an
> argument about GCC internals. Presumably these hypothetical BLKmode
> types would need to support addition,
I don’t recall seeing that as a requirement in the dwarf st
Mike Stump writes:
> On Nov 2, 2015, at 12:55 PM, Richard Sandiford
> wrote:
>> This was:
>>
>> ... Sometimes structure decls
>> have BLKmode but are assigned an integer-mode rtl (e.g. when passing
>> 3-byte structures by value to functions).
>> [...]
>> loc_descriptor refuses to use CONST_
On Nov 2, 2015, at 12:55 PM, Richard Sandiford
wrote:
> This was:
>
> ... Sometimes structure decls
> have BLKmode but are assigned an integer-mode rtl (e.g. when passing
> 3-byte structures by value to functions).
> [...]
> loc_descriptor refuses to use CONST_INT for BLKmode decls (which a
Mike Stump writes:
> On Nov 2, 2015, at 8:29 AM, Richard Sandiford
> wrote:
>> switch (GET_CODE (rtl))
>> {
>> case CONST_INT:
>> - {
>> -HOST_WIDE_INT val = INTVAL (rtl);
>> + if (mode != BLKmode)
>
> This changes BLKmode for CONST_INT, but I didn’t see this discussed.
On Nov 2, 2015, at 8:29 AM, Richard Sandiford wrote:
> switch (GET_CODE (rtl))
> {
> case CONST_INT:
> - {
> - HOST_WIDE_INT val = INTVAL (rtl);
> + if (mode != BLKmode)
This changes BLKmode for CONST_INT, but I didn’t see this discussed. I didn’t
see a test case? I’d l
Richard Sandiford writes:
> gcc/
> PR debug/66728
> * dwarf2out.c (loc_descriptor): Remove redundant GET_MODE of
> CONST_WIDE_INTs. Handle BLKmode for CONST_WIDE_INT too.
> (add_const_value_attribute): Add a mode parameter.
> Check it for CONST_INT and CONST_WIDE_INT
Bernd Schmidt writes:
> On 10/28/2015 02:06 PM, Richard Sandiford wrote:
>> Ulrich Weigand writes:
>>> seems this still hasn't gone upstream ... Any news?
>>
>> Ah, sorry, I should have been pinging it. I think it's still waiting
>> for review.
>
> Hmm, unfortunately I have a hard time making s
Bernd Schmidt wrote:
> This is all a bit html mangled, but this and the other change in
> loc_descriptor seem to have the effect of doing nothing when called with
> BLKmode. What is the desired effect of this on the debug information,
> and how is it achieved?
Sorry for the mangling caused by
On 10/28/2015 02:06 PM, Richard Sandiford wrote:
Ulrich Weigand writes:
seems this still hasn't gone upstream ... Any news?
Ah, sorry, I should have been pinging it. I think it's still waiting
for review.
Hmm, unfortunately I have a hard time making sense of this patch. Some
extra explan
Ulrich Weigand writes:
> Hi Richard,
>
> seems this still hasn't gone upstream ... Any news?
Ah, sorry, I should have been pinging it. I think it's still waiting
for review.
Thanks,
Richard
>> This is yet another bug caused by rtx having modeless scalar integer
>> constants. We need to use c
Hi Richard,
seems this still hasn't gone upstream ... Any news?
Thanks,
Ulrich
> This is yet another bug caused by rtx having modeless scalar integer
> constants. We need to use context to find the actual mode of a
> CONST_INT or CONST_WIDE_INT.
>
> Getting a mode is especially awkward here.
On Sat, Aug 22, 2015 at 10:02 AM, Uros Bizjak wrote:
> Hello!
>
>> This is yet another bug caused by rtx having modeless scalar integer
>> constants. We need to use context to find the actual mode of a
>> CONST_INT or CONST_WIDE_INT.
>
> +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr66728.c
> @@ -0,0
Hello!
> This is yet another bug caused by rtx having modeless scalar integer
> constants. We need to use context to find the actual mode of a
> CONST_INT or CONST_WIDE_INT.
+++ b/gcc/testsuite/gcc.dg/debug/dwarf2/pr66728.c
@@ -0,0 +1,14 @@
+/* { dg-do compile { target { x86_64-*-* && lp64 } } }
On 08/21/2015 07:58 AM, Richard Sandiford wrote:
This is yet another bug caused by rtx having modeless scalar integer
constants. We need to use context to find the actual mode of a
CONST_INT or CONST_WIDE_INT.
We've been bumping into these as long as I can remember. I suspect I
still have a gr
This is yet another bug caused by rtx having modeless scalar integer
constants. We need to use context to find the actual mode of a
CONST_INT or CONST_WIDE_INT.
Getting a mode is especially awkward here. Decls have two modes
associated with them: TYPE_MODE (TREE_TYPE (decl)) and DECL_MODE (decl)
25 matches
Mail list logo
