Mike Stump writes:
> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
> wrote:
>>> * When a constant that has an integer type is converted to a
>>>wide-int it comes in with precision 0. For these constants the
>>>top bit does accurately reflect the sign of that constant; this
>>>is an
> Hi,
>
> On 08/23/2013 05:12 PM, Jan Hubicka wrote:
> >+/* { dg-final { scan-tree-dump-nop "A::foo" 0 "ssa"} } */
> This should be scan-tree-dump-not right?
Yes, thanks! Seems that scan-tree-dump-nop does what name suggests.
I will fix it shortly.
Honza
>
> Paolo.
> On 08/23/2013 10:51 AM, Jan Hubicka wrote:
> >Sadly we ICE here because BINFO of type is not built yet.
> >I tried to move the code after xref_binfos and it does seem to lead to errors
> >while building libstdc++ PCH. Any idea what to do here?
>
> If it's causing trouble, let's just put the fla
Kenneth Zadeck writes:
>>> * Code that does widening conversions. The canonical way that
>>>this is performed is to sign or zero extend the input value to
>>>the max width based on the sign of the type of the source and
>>>then to truncate that value to the target typ
On Fri, Aug 23, 2013 at 2:47 AM, John David Anglin wrote:
> Ping.
>
>
> On 28-Jul-13, at 12:17 PM, John David Anglin wrote:
>
>> This patch fixes PR middle-end/56382 on hppa64-hp-hpux11.11. The patch
>> prevents moving a complex float by parts if we can't
>> create pseudos. On a big endian 64-bit
Richard Sandiford writes:
> I wonder how easy it would be to restrict this use of "zero precision"
> (i.e. flexible precision) to those where primitive types like "int" are
> used as template arguments to operators, and require a precision when
> constructing a wide_int. I wouldn't have expected
ping
> Given that I did not receive any feedback on my earlier email on this topic,
> I would like to send this patch for RFC. I'm not expert at this
> configury-stuff, so please try to comment on both the test proposed and my
> actual implementation :)
>
> The idea is to find a patch which b
On 24-Aug-13, at 6:43 AM, Steven Bosscher wrote:
I'm trying to understand how the patch would help...
The code you're patching is:
/* Move floating point as parts. */
if (GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT
+&& can_create_pseudo_p ()
&& optab_handler (mov_optab, GET_MODE_I
On Sun, Aug 18, 2013 at 08:19:57PM +0200, Jan Hubicka wrote:
> Hi,
> this patch implements the type inheritance graph builder. Once the graph is
> built it stays in memory and unchanged thorough the compilation (we do not
> expect to invent new virtual methods during the optimization)
> The graph i
On 24-Aug-13, at 10:37 AM, John David Anglin wrote:
On 24-Aug-13, at 6:43 AM, Steven Bosscher wrote:
I'm trying to understand how the patch would help...
The code you're patching is:
/* Move floating point as parts. */
if (GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT
+&& can_create_pseu
Hi,
the patch below does not punt when creating pass through and ancestor
jump functions when there is a possible dynamic type change detected
but rather clears a flag in those functions. Indirect inlining and
IPA-CP then make sure they only propagate when the flag is set.
I have also merged one
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford writes:
I wonder how easy it would be to restrict this use of "zero precision"
(i.e. flexible precision) to those where primitive types like "int" are
used as template arguments to operators, and require a precision when
constru
On 08/13/2013 10:57 PM, Kenneth Zadeck wrote:
1) The 4 files that hold the wide-int code itself. You have seen a
lot of this code before except for the infinite precision
templates. Also the classes are more C++ than C in their flavor.
In particular, the integration with trees is ve
On 08/24/2013 02:16 PM, Florian Weimer wrote:
On 08/13/2013 10:57 PM, Kenneth Zadeck wrote:
1) The 4 files that hold the wide-int code itself. You have seen a
lot of this code before except for the infinite precision
templates. Also the classes are more C++ than C in their flavor.
On Thu, Aug 15, 2013 at 11:21 AM, Yufeng Zhang wrote:
> Ping^4~
>
> I am aware that it is currently holiday season, but it would be really nice
> if this tiny patch can get some further comments even if it is not an
> approval.
>
> The original RFA email is here:
> http://gcc.gnu.org/ml/gcc-patche
fixed with the enclosed patch.
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
/* Return true if THIS is negative based on the interpretation of SGN.
For UNSIGNED, this is always false. This is correct even if
precision is 0. */
inline bool
wide_int::neg_p (signop sgn) const
It seems
The patch goes for (1) but (2) seems better to me, for a few reasons:
* As above, constants coming from rtl are already in the right form,
so if you create a wide_int from an rtx and only query it, no explicit
extension is needed.
* Things like logical operations and right shifts natur
On 08/24/2013 05:18 AM, Jan Hubicka wrote:
In the next step I would like to introduce the DECL_CPP_CONSTRUCTOR/DESTRUCTOR
macro.
The catch I run into is that these flags are tested on TEMPLATE_DECL so the
middle-end
macro bombs on type checking. I wonder what is best approach here.
I think f
Hi,
I've been working on a SH specific RTL pass and just adapted it to the
new pass handling. One thing that bugged me was pass registration. How
about adding an overload for 'register_pass' as in the attached patch?
Registering a pass is then as simple as:
register_pass (make_new_ifcvt_sh (g
On 23 August 2013 16:05:32 Zoran Jovanovic wrote:
Hello,
This is new patch version. Optimization does not use BIT_FIELD_REF any
more, instead it generates new COMPONENT_REF and FIELD_DECL.
Existing Bit field representative is associated with newly created field
declaration.
During analysis pha
Most of the specialized pretty printing functions from the C-family
languages are really virtual functions. This patchlet makes the first
explicitly so.
Tested on an x86_64-suse-linux. Applied to trunk.
-- Gaby
c-family/
2013-08-24 Gabriel Dos Reis
* c-pretty-print.h (c_pretty_p
Same as previous topic; for id_expression.
-- Gaby
2013-08-24 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::id_expression): Now a
virtual function.
(pp_c_id_expression): Remove.
(pp_id_expression): Adjust.
* c-pretty-print.c (c_pretty
Instead of defining the same macro several times in different
translation units, we can just make it a function and use it where
needed.
Tested on an x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-25 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::translate
Kenneth Zadeck writes:
> On 08/24/2013 08:05 AM, Richard Sandiford wrote:
>> Richard Sandiford writes:
>>> I wonder how easy it would be to restrict this use of "zero precision"
>>> (i.e. flexible precision) to those where primitive types like "int" are
>>> used as template arguments to operators
24 matches
Mail list logo
