I adjusted logic in patch for interger zero/all-one case for bit
and/or. By simply copying the variable operand to destination,
without checking for valid ranges for and-expression with all-ones and
or-expression with zero operand, logic could be simplified pretty
much.
I adjusted names for varia
Hi David,
I've been looking into what we need to do to support unwinding from
async signal handlers. I've implemented unwind info generation for
.glink in the linker, but to keep the ppc64 .glink unwind info simple
I've assumed that frob_update_context is still used.
We still have some difficul
Hi,
The offsetted memory references always work for x32. OK for trunk?
Thanks.
H.J.
2011-07-26 H.J. Lu
PR target/49860
* config/i386/predicates.md (x86_64_immediate_operand): Always
allow the offsetted memory references for TARGET_X32.
(x86_64_zext_immed
Hi,
For x32, movabs is only supported with register and constant operands.
OK for trunk?
Thanks.
H.J.
2011-07-26 H.J. Lu
* config/i386/predicates.md (x86_64_movabs_operand): Don't allow
nonmemory_operand for TARGET_X32.
diff --git a/gcc/config/i386/predicates.md b/gcc/conf
Le-Chun added the additional routine to remove pointers from a set;
that code is unique to annotalysis. I can't easily include a test
case, because the bug is difficult to trigger. It occurs only when
there is a hash collision between two pointers in the set, and the
first pointer is removed befo
This is the main patch which implements all the code for the new
__sync_mem routines which take a memory model as a parameter.
I used the previously approved and checked in __sync_mem_exchange
routine as the model and added all the rest. The only difference is I'm
not adding the x86 patterns y
This patch is simply the documentation for extend.texi which adds a
section about the new memory model __sync_mem routines. I've supplied
the .info output since its easier to read, followed by the patch
OK for the branch?
Andrew
6.52 Built-in functions for memory model aware atomic operation
On Tue, Jul 26, 2011 at 16:13, Delesley Hutchins wrote:
> This patch fixes a bug in pointer_set.c, where removing a pointer from
> a pointer set would corrupt the hash table if the pointer was involved
> in any hash collisions.
Could you include a test case? It's not clear to me what you are
fix
This patch fixes a bug in pointer_set.c, where removing a pointer from
a pointer set would corrupt the hash table if the pointer was involved
in any hash collisions.
Bootstrapped and passed gcc regression testsuite on x86_64-unknown-linux-gnu.
Okay for google/gcc-4_6?
-DeLesley
gcc/Changelog.
See comments inline.
> +
> +/* PPH write/read */
> +
> +
> +/* Emit a tinst_level list TINST to STREAM. */
> +
> +static void
> +pph_out_tinst_level (pph_stream *stream, struct tinst_level *tinst)
> +{
> + int count;
> + struct tinst_level *cur;
> +
> + /* Count the number of items. */
> + f
This patch copies the source location of a FUNCTION_DECL to the
TEMPLATE_DECL that build_template_decl() builds out of it. Otherwise,
the TEMPLATE_DECL's location becomes input_location, which is the end
of the parameter list, while the FUNCTION_DECL's location is the
location of the name of the fu
On 07/26/2011 01:38 PM, Jakub Jelinek wrote:
> * dwarf2out.c (output_macinfo_op): Ensure fd->filename points
> to GC allocated copy of the string.
> (dwarf2out_finish): Emit .debug_macinfo or .debug_macro sections
> before .debug_line, not after it.
Ok.
r~
On Tue, Jul 26, 2011 at 10:38:09PM +0200, Jakub Jelinek wrote:
> With that I've discovered that lookup_filename assumes that the string
> it is called in is kept around, as it stores just the pointer and not a copy
> of that string. It seems all other places that call lookup_filename already
> cal
Committed.
--
DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
On Tue, Jul 26, 2011 at 10:33 PM, H.J. Lu wrote:
> On Tue, Jul 26, 2011 at 1:29 PM, Jakub Jelinek wrote:
>> On Tue, Jul 26, 2011 at 10:21:11PM +0200, Uros Bizjak wrote:
>>> This also works, we look at orig_x that looks like:
>>>
>>> (mem/u/c:SI (const:DI (unspec:DI [
>>> (symbol_r
Hi!
I've noticed that -g3 (both old .debug_macinfo and new .debug_macro) doesn't
work correctly when HAVE_AS_DWARF2_DEBUG_LINE isn't defined, because
the .debug_line section is emitted before .debug_mac{ro,info} and thus
if any DW_MACINFO_start_file/DW_MACRO_GNU_start_file ops need a file
that was
On Tue, Jul 26, 2011 at 1:29 PM, Jakub Jelinek wrote:
> On Tue, Jul 26, 2011 at 10:21:11PM +0200, Uros Bizjak wrote:
>> This also works, we look at orig_x that looks like:
>>
>> (mem/u/c:SI (const:DI (unspec:DI [
>> (symbol_ref:SI ("__sflush") [flags 0x41]
>> )
>> ] UNS
On Tue, Jul 26, 2011 at 10:21:11PM +0200, Uros Bizjak wrote:
> This also works, we look at orig_x that looks like:
>
> (mem/u/c:SI (const:DI (unspec:DI [
> (symbol_ref:SI ("__sflush") [flags 0x41]
> )
> ] UNSPEC_GOTPCREL)) [2 S4 A8])
>
> So, we look at SImode load, and
On Tue, Jul 26, 2011 at 10:12 PM, Jakub Jelinek wrote:
> On Tue, Jul 26, 2011 at 10:05:06PM +0200, Uros Bizjak wrote:
>> > 2011-07-26 H.J. Lu
>> >
>> > PR target/47372
>> > * config/i386/i386.c (ix86_delegitimize_address): Call
>> > simplify_gen_subreg for PIC with ptr_mode
Hi!
Double arguments passed on the stack on x86_64 (and float too) where
a function is called with a constant is stored using corresponding integer
mode rather than DFmode, so cselib_lookup doesn't find the preserved value
for this. Fixed thusly, bootstrapped/regtested on x86_64-linux and
i686-li
On Tue, Jul 26, 2011 at 10:05:06PM +0200, Uros Bizjak wrote:
> > 2011-07-26 H.J. Lu
> >
> > PR target/47372
> > * config/i386/i386.c (ix86_delegitimize_address): Call
> > simplify_gen_subreg for PIC with ptr_mode only if modes of
> > x and orig_x are different.
> >
>
The attached patch fixes PR 49755, allowing GFortran to behave correctly
when faced with multiple allocations:
allocate(A(20,20))
A = 42
! Allocate of already allocated variable
allocate (A(5,5), stat=stat)
The patch fixes an error in the test suite (multiple_allocation_1.f90
On Tue, Jul 26, 2011 at 9:41 PM, H.J. Lu wrote:
> We should call simplify_gen_subreg for PIC with ptr_mode only if modes
> of x and orig_x are different. OK for trunk?
Let's ask Jakub on this one...
Uros.
> 2011-07-26 H.J. Lu
>
> PR target/47372
> * config/i386/i386.c (ix86_d
This patch tests for at least one user-caused reason for this
assertion failing - requiring a local frame in a naked function. For
this case at least, it would be better to trigger an error than to
ICE. OK?
static int bar;
void __attribute__((naked)) function(void) {
int foo, result;
resu
The patch is committed to google/main to fix lipo test regressions after trunk
merge.
2011-07-26 David Li
* value-prof.c (gimple_value_profile_transformations): Remove redundant
code.
* cgraphunit.c (cgraph_mark_functions_to_output): Fix assertion in lipo
mode.
* ipa
Hi,
Hi,
We should call simplify_gen_subreg for PIC with ptr_mode only if modes
of x and orig_x are different. OK for trunk?
Thanks.
H.J.
---
2011-07-26 H.J. Lu
PR target/47372
* config/i386/i386.c (ix86_delegitimize_address): Call
simplify_gen_subreg for PIC with p
If a function is both a leaf function and an interrupt function, leaf
register renumbering causes the wrong set of registers to be saved.
This patch disables renumbering for interrupt functions.
* config/rx/rx.c (rx_leaf_registers): New.
(rx_set_leaf_registers): New.
(rx_e
On 07/25/11 18:55, Jason Merrill wrote:
On 07/25/2011 10:07 AM, Aldy Hernandez wrote:
I had changed this already to take into account aliasing, so if we get
an INDIRECT_REF, ptr_deref_may_alias_global_p() returns true, and we
proceed with the restriction:
Sounds good. "global" includes malloc'
On Tue, 26 Jul 2011, Georg-Johann Lay wrote:
> I once ran into trouble because there seems to be no clear
> separation between undefinedness in C and undefinedness in RTL
>
> Starting thread from here,
> http://gcc.gnu.org/ml/gcc-help/2010-06/msg00191.html
>
> the treads comes to this
> http
Rainer Orth wrote:
> sure, that's one of the reasons to centralize the mmap test. Simply
> replacing the body of the proc with
>
> return [check_function_available "mmap"]
>
> should work. Could you give it a try?
Yes, this does work for me.
Thanks,
Ulrich
ChangeLog:
* lib/tar
The following patch decreases existing code size degradation on ARM by
permitting a special case of early clobber without reloads, for example,
for pattern
;; Use `&' and then `0' to prevent the operands 0 and 1 being the same
(define_insn "*arm_mulsi3"
[(set (match_operand:SI 0 "s_r
Richard Henderson wrote:
> On 07/26/2011 10:26 AM, Georg-Johann Lay wrote:
>> If -mint8 (word_mode = QImode) ever returns resp. is turned
>> functional again, then the QI version is undefined for
>> offsets >= 8 whereas the HI version is only undefined for
>> offsets >= 16.
>
> It's undefined at
This patch saves and restores three template side tables for PPH. They are
the pending template instantiations list, the template decl specializations
table, and the template type specializations table.
This patch fixes PPH test x1tmplclass.
In the process, I mace lto_output_location and lto_inp
On Sat, Jul 23, 2011 at 04:59, Richard Guenther
wrote:
> On Sat, Jul 23, 2011 at 1:01 AM, Sebastian Pop wrote:
>> The CLAST produced by CLooG-ISL contains an assignment and GCC chokes
>> on it. The exact CLAST contains an assignment followed by an if:
>>
>> scat_1 = max(0,ceild(T_4-7,8));
>> if
On Thu, Jul 21, 2011 at 18:45, Sebastian Pop wrote:
> Hi Tobias,
>
> On Thu, Jul 21, 2011 at 18:00, Tobias Grosser wrote:
>> Hi,
>>
>> I propose to switch to the official cloog.org cloog version with isl backend
>> and
>> at the same time to remove support for both CLooG-PPL legacy as well as
>>
On Fri, Jul 22, 2011 at 07:32, Joseph S. Myers wrote:
> On Fri, 22 Jul 2011, Tobias Grosser wrote:
>
>> I propose to switch to the official cloog.org cloog version with isl backend
>> and
>> at the same time to remove support for both CLooG-PPL legacy as well as
>> CLooG-Parma.
>
> Where are the
On 07/26/2011 08:00 PM, Ian Lance Taylor wrote:
Ping.
On Thu, Jul 21, 2011 at 11:20 PM, Ian Lance Taylor wrote:
One of my recent patches broke the toplevel configury. I moved a test
of $configdirs to a point before nonexistent directories have been
removed from configdirs. The test was for w
"H.J. Lu" writes:
> I checked in this as an obvious fix.
Thanks. I wonder why I didn't see that.
Ian
+ bitnum -= bitregion_start;
+ bitregion_end -= bitregion_start;
+ bitregion_start = 0;
Why is this necessary/useful?
You mean, why am I resetting these values (because the call to
get_best_mode() following it needs the adjusted values). Or why am I
adjusting the address to point to the b
Ulrich,
> Rainer Orth wrote:
>
>> +proc check_effective_target_mmap {} {
>> +return [check_no_compiler_messages mmap assembly {
>> +#include
>> +}]
>> +}
>
> Unfortunately, this test breaks spu-elf; a lot of tests now fail with:
> loop-2f.c:(.text+0x100): undefined reference to `mmap'
OK.
Jason
On Tue, Jul 26, 2011 at 08:30, Richard Guenther
wrote:
> I suppose we also need to allow POINTER_TYPE_P here (but then
> treat it like an unsigned variable of the same width).
Updated patch. Ok for trunk after regstrap?
Thanks,
Sebastian
From 3e8f8cfd0c4298b6b5e88c8bc7ba81a01e7cd815 Mon Sep 17
On Tue, Jul 26, 2011 at 7:50 PM, H.J. Lu wrote:
> This patch fixes PIC with external symbol and updates
> x86_64_immediate_operand/x86_64_zext_immediate_operand/x86_64_movabs_operand
> for x32.
> 2011-07-26 H.J. Lu
>
> PR target/49853
> * config/i
Ping.
On Thu, Jul 21, 2011 at 11:20 PM, Ian Lance Taylor wrote:
> One of my recent patches broke the toplevel configury. I moved a test
> of $configdirs to a point before nonexistent directories have been
> removed from configdirs. The test was for whether gcc is being
> configured. The test i
Rainer Orth wrote:
> +proc check_effective_target_mmap {} {
> +return [check_no_compiler_messages mmap assembly {
> + #include
> +}]
> +}
Unfortunately, this test breaks spu-elf; a lot of tests now fail with:
loop-2f.c:(.text+0x100): undefined reference to `mmap'
The problem is that
On Tue, Jul 26, 2011 at 10:56, Sebastian Pop wrote:
> On Tue, Jul 26, 2011 at 10:43, Richard Guenther wrote:
>> Please make graphite more robust instead.
>
> Ok, in this case, what about setting gloog_error and stopping the code
> generation instead of failing on this gcc_assert.
>
Here is the p
On Tue, Jul 26, 2011 at 10:36 AM, Uros Bizjak wrote:
> On Tue, Jul 26, 2011 at 7:31 PM, H.J. Lu wrote:
>
This patch fixes PIC with external symbol and updates
x86_64_immediate_operand/x86_64_zext_immediate_operand/x86_64_movabs_operand
for x32.
>>>
2011-07-26 H.J. Lu
>
On 07/26/2011 10:32 AM, Aldy Hernandez wrote:
I think the adjustment above is intended to match the adjustment of the
address by bitregion_start/BITS_PER_UNIT, but the above seems to assume
that bitregion_start%BITS_PER_UNIT == 0.
That was intentional. bitregion_start always falls on a byte b
On Tue, Jul 26, 2011 at 7:31 PM, H.J. Lu wrote:
>>> This patch fixes PIC with external symbol and updates
>>> x86_64_immediate_operand/x86_64_zext_immediate_operand/x86_64_movabs_operand
>>> for x32.
>>
>>> 2011-07-26 H.J. Lu
>>>
>>> PR target/49853
>>> * config/i386/i386.c (ix86
On 07/26/2011 09:36 AM, Aldy Hernandez wrote:
+ bitnum -= bitregion_start;
+ bitregion_end -= bitregion_start;
+ bitregion_start = 0;
Why is this necessary/useful?
You mean, why am I resetting these values (because the call to
get_best_mode() following it needs the adjusted values). Or why
I think the adjustment above is intended to match the adjustment of the
address by bitregion_start/BITS_PER_UNIT, but the above seems to assume
that bitregion_start%BITS_PER_UNIT == 0.
That was intentional. bitregion_start always falls on a byte boundary,
does it not?
struct {
stuf
On Tue, Jul 26, 2011 at 10:26 AM, Uros Bizjak wrote:
> On Tue, Jul 26, 2011 at 4:59 PM, H.J. Lu wrote:
>
>> This patch fixes PIC with external symbol and updates
>> x86_64_immediate_operand/x86_64_zext_immediate_operand/x86_64_movabs_operand
>> for x32.
>
>> 2011-07-26 H.J. Lu
>>
>> PR
On 07/26/2011 10:26 AM, Georg-Johann Lay wrote:
> If -mint8 (word_mode = QImode) ever returns resp. is turned
> functional again, then the QI version is undefined for
> offsets >= 8 whereas the HI version is only undefined for
> offsets >= 16.
It's undefined at the C level, not necessarily at the
Richard Henderson wrote:
> On 07/26/2011 02:48 AM, Georg-Johann Lay wrote:
>> Moreover, the original peep2 is not fully correct because it
>> maps a 16-bit shift to a 8-bit one. The correct mapping is
>>
>> (set (match_dup 2)
>> (subreg:QI (ashift:HI (zero_extend:HI (match_dup 2))
>>
On Tue, Jul 26, 2011 at 4:59 PM, H.J. Lu wrote:
> This patch fixes PIC with external symbol and updates
> x86_64_immediate_operand/x86_64_zext_immediate_operand/x86_64_movabs_operand
> for x32.
> 2011-07-26 H.J. Lu
>
> PR target/49853
> * config/i386/i386.c (ix86_expand_move): C
On Tue, Jul 26, 2011 at 09:39:02AM +0200, Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 7:52 PM, Martin Jambor wrote:
...
> >
> > 2011-07-25 Martin Jambor
> >
> > * tree-sra.c (tree_non_mode_aligned_mem_p): Strip conversions and
> > return false for invariants.
> >
> > Index
On Tue, Jul 26, 2011 at 9:46 AM, H.J. Lu wrote:
> On Tue, Jul 26, 2011 at 7:30 AM, Ian Lance Taylor wrote:
>> binutils PR 13030 reports a demangler crash on the symbol
>> _ZSt10_ConstructI10CellBorderIS0_EEvPT_DpOT0_
>>
>> As far as I can tell, this symbol is invalid. The final T0_ refers to
Michael Matz wrote:
> On Tue, 26 Jul 2011, Michael Matz wrote:
> > On Tue, 26 Jul 2011, Ulrich Weigand wrote:
> >
> > > > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > > > we'd need to pick a conservative REGNO_POINTER_ALIGN during
> > > > expansion of the SSA name partiti
On Tue, Jul 26, 2011 at 7:30 AM, Ian Lance Taylor wrote:
> binutils PR 13030 reports a demangler crash on the symbol
> _ZSt10_ConstructI10CellBorderIS0_EEvPT_DpOT0_
>
> As far as I can tell, this symbol is invalid. The final T0_ refers to
> template argument 1, but this zero-based index has no
2011/7/25 Jakub Jelinek :
> On Mon, Jul 25, 2011 at 09:10:55PM +0200, Romain Geissler wrote:
>> > 2011-07-18 Romain Geissler
>> >
>> > * gengtype-state.c (#include "bconfig.h"): Include "bconfig.h"
>> > if GENERATOR_FILE is defined, "config.h" otherwise.
>
> Still not right, this should
Hi,
On Tue, 26 Jul 2011, Michael Matz wrote:
> On Tue, 26 Jul 2011, Michael Matz wrote:
>
> > Hi,
> >
> > On Tue, 26 Jul 2011, Ulrich Weigand wrote:
> >
> > > > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > > > we'd need to pick a conservative REGNO_POINTER_ALIGN durin
Hi,
jimis noticed this on IRC. Since r160348 there's some dead code in
df_update_entry_block_defs and df_update_exit_block_uses. I'm currently
regstrapping this together with the pointer alignment merging patch on
x86_64-linux, and am going to commit it as obvious when that works.
Ciao,
Mic
Hello!
Using mode iterator, we can use x86_64_nonmemory_operand where
appropriate and remove extra pattern (and ??? comment) on the way.
2011-07-26 Uros Bizjak
* config/i386/i386.md (add->lea splitter): Implement using SWI
mode iterator. Change operand 2 predicate to .
On Tue, Jul 26, 2011 at 10:43, Richard Guenther wrote:
> Required? Do you mean you generate wrong code in graphite if it is
> not run?
Graphite won't generate wrong code if scev_cprop is not run: it will
fail on an assert in the code generation part. We used to know the
scev for the induction v
On Tue, Jul 26, 2011 at 5:40 PM, Mike Stump wrote:
> On Jul 26, 2011, at 7:50 AM, Kirill Yukhin wrote:
>> I've also prepared a bunch of tests for lzcnt instuction generation..
>
>> /ChangeLog entry:
>> 2011-07-26 Kirill Yukhin
>>
>> * lib/target-supports.exp (check_lzcnt_hw_available): New.
On Tue, 26 Jul 2011, Michael Matz wrote:
> Hi,
>
> On Tue, 26 Jul 2011, Ulrich Weigand wrote:
>
> > > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > > we'd need to pick a conservative REGNO_POINTER_ALIGN during
> > > expansion of the SSA name partition - iterate over all
"H.J. Lu" writes:
> On Tue, Jul 26, 2011 at 7:30 AM, Ian Lance Taylor wrote:
>> binutils PR 13030 reports a demangler crash on the symbol
>> _ZSt10_ConstructI10CellBorderIS0_EEvPT_DpOT0_
>>
>> As far as I can tell, this symbol is invalid. The final T0_ refers to
>> template argument 1, but t
On Tue, Jul 26, 2011 at 7:30 AM, Ian Lance Taylor wrote:
> binutils PR 13030 reports a demangler crash on the symbol
> _ZSt10_ConstructI10CellBorderIS0_EEvPT_DpOT0_
>
> As far as I can tell, this symbol is invalid. The final T0_ refers to
> template argument 1, but this zero-based index has no
Bug found at last, it's in the following hunk, the ampersand in
&exit_block_uses is wrong... :-@
@@ -3951,7 +3949,7 @@ df_get_exit_block_use_set (bitmap exit_b
{
rtx tmp = EH_RETURN_STACKADJ_RTX;
if (tmp && REG_P (tmp))
- df_mark_reg (tmp, exit_block_uses);
+ df_
On Tue, 26 Jul 2011, Sebastian Pop wrote:
> On Tue, Jul 26, 2011 at 09:33, Richard Guenther wrote:
> > On Tue, 26 Jul 2011, Sebastian Pop wrote:
> >
> >> Ping.
> >> Any opinions on this patch?
> >
> > Well, I don't think we should do this. Why does the user disable
> > scev-const-prop when enabl
On Tue, Jul 26, 2011 at 09:33, Richard Guenther wrote:
> On Tue, 26 Jul 2011, Sebastian Pop wrote:
>
>> Ping.
>> Any opinions on this patch?
>
> Well, I don't think we should do this. Why does the user disable
> scev-const-prop when enabling graphite? If he does so, fine - he
> has to live with
This applies overflow heuristics to maybe_hot_frequency_p to make
sure not everything is thought to be cold (which happens when
building polyhedron AIR with -fwhole-program).
Bootstrapped and tested on x86_64-unknown-linux-gnu, approved by
Honza on IRC.
Richard.
2011-07-26 Richard Guenther
Any updates/questions on this?
On 18 July 2011 15:00, Michael Zolotukhin
wrote:
> Here is a summary - probably, it doesn't cover every single piece in
> the patch, but I tried to describe the major changes. I hope this will
> help you a bit - and of course I'll answer your further questions if
>
On Jul 26, 2011, at 7:50 AM, Kirill Yukhin wrote:
> I've also prepared a bunch of tests for lzcnt instuction generation..
> /ChangeLog entry:
> 2011-07-26 Kirill Yukhin
>
>* lib/target-supports.exp (check_lzcnt_hw_available): New.
>(check_effective_target_lzcnt_runtime): Likewise.
>
On 07/26/2011 02:48 AM, Georg-Johann Lay wrote:
> Moreover, the original peep2 is not fully correct because it
> maps a 16-bit shift to a 8-bit one. The correct mapping is
>
> (set (match_dup 2)
> (subreg:QI (ashift:HI (zero_extend:HI (match_dup 2))
>(match_dup 1)
"H.J. Lu" writes:
> One of cp-demangle.c changes in June/July caused:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49852
Already fixed. However, there may be a compiler bug in that the symbol
was generated in the first place.
Ian
> So don't lie to GCC then? You specify
>
> struct X { char c; int i; } __attribute__((packed)) x;
>
> and expect that GCC knows x.i is aligned to 4 bytes!?
The actual header is much more complex than this trivial example.
It also fails with this example, where the port_status[] array *is*
ob
Hi,
This patch fixes PIC with external symbol and updates
x86_64_immediate_operand/x86_64_zext_immediate_operand/x86_64_movabs_operand
for x32.
H.J.
2011-07-26 H.J. Lu
PR target/49853
* config/i386/i386.c (ix86_expand_move): Call convert_to_mode
on legitimize_tls_
Hi,
I've prepared a patch for http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49547
I've also prepared a bunch of tests for lzcnt instuction generation.
ChangeLog entry:
2011-07-26 Kirill Yukhin
PR target/49547
* config/i386/abmintrin.h (head): Added check if __LZCNT__ is defined.
On Tue, 26 Jul 2011, Sebastian Pop wrote:
> On Tue, Jul 26, 2011 at 09:07, Richard Guenther wrote:
> >> > Randomly sign-extending stuff looks bogus to me.
> >> > Does graphite operate on infinite precision signed integers? Or
> >> > does it operate on twos-complement fixed precision integers?
>
On Tue, 26 Jul 2011, Sebastian Pop wrote:
> Ping.
> Any opinions on this patch?
Well, I don't think we should do this. Why does the user disable
scev-const-prop when enabling graphite? If he does so, fine - he
has to live with worse codegen.
Richard.
> Thanks,
> Sebastian
>
> On Sat, Jul 23,
binutils PR 13030 reports a demangler crash on the symbol
_ZSt10_ConstructI10CellBorderIS0_EEvPT_DpOT0_
As far as I can tell, this symbol is invalid. The final T0_ refers to
template argument 1, but this zero-based index has no referent since the
template only has one parameter. This of cour
Ping.
Any opinions on this patch?
Thanks,
Sebastian
On Sat, Jul 23, 2011 at 23:40, Sebastian Pop wrote:
> This patch makes graphite run the scev_const_prop systematically even
> when using -fno-tree-scev-cprop. When scev_const_prop is not applied,
> there exist close_phi nodes for the main indu
On Tue, Jul 26, 2011 at 09:07, Richard Guenther wrote:
>> > Randomly sign-extending stuff looks bogus to me.
>> > Does graphite operate on infinite precision signed integers? Or
>> > does it operate on twos-complement fixed precision integers?
>>
>> Graphite represents constants using mpz_t.
>
>
On Tue, 26 Jul 2011, Sebastian Pop wrote:
> On Tue, Jul 26, 2011 at 03:22, Richard Guenther wrote:
> > On Mon, 25 Jul 2011, Sebastian Pop wrote:
> >
> >> "Bug 47594 - gfortran.dg/vect/vect-5.f90 execution test fails when
> >> compiled with -O2 -fgraphite-identity"
> >>
> >> The problem is due to
On Tue, Jul 26, 2011 at 03:22, Richard Guenther wrote:
> On Mon, 25 Jul 2011, Sebastian Pop wrote:
>
>> "Bug 47594 - gfortran.dg/vect/vect-5.f90 execution test fails when
>> compiled with -O2 -fgraphite-identity"
>>
>> The problem is due to the fact that Graphite generates this loop:
>>
>> for
Hi,
One of cp-demangle.c changes in June/July caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49852
--
H.J.
Hi,
On Tue, 26 Jul 2011, Ulrich Weigand wrote:
> > Well, REG_ATTRS->decl is again a decl, not an SSA name. I suppose
> > we'd need to pick a conservative REGNO_POINTER_ALIGN during
> > expansion of the SSA name partition - iterate over all of them in the
> > partition and pick the lowest alignme
Richard Guenther wrote:
> On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand wrote:
> > When would that be? The expansion does happen in the initial expand
> > stage, but I'm getting called from the middle-end via emit_move_insn etc.
> > which already provides me with a MEM ...
>
> Hmm. I suppose
On Tue, Jul 26, 2011 at 2:59 PM, Razya Ladelsky wrote:
> Richard Guenther wrote on 25/07/2011 05:54:28
> PM:
>
>> From: Richard Guenther
>> To: Razya Ladelsky/Haifa/IBM@IBMIL
>> Cc: gcc-patches@gcc.gnu.org, Zdenek Dvorak
>> , Sebastian Pop
>> Date: 25/07/2011 05:54 PM
>> Subject: Re: [patch] Fi
Hi
I added some new closures i needed for my plugin that i think worth
being shared to all melt users.
I also removed "string=" and "string!=" primitives, as "==s" and "!=s"
just do the same.
Romain Geissler
melt-utils2.Changelog
Description: Binary data
melt-utils2.diff
Description: Binary d
2011/7/26 Rainer Orth :
> I'm in the middle of moving shlib support (another day), need to rebase
> crtstuff and libgcc1, and finish libgcc2.
>
> I hope to be ready within two or three weeks.
Ok then. I'd appreciate if you can send me a reminder via private
mail when you've finished.
Best regard
On 07/25/2011 10:33 AM, Andrew Haley wrote:
> On 21/07/11 16:33, Joseph S. Myers wrote:
>> My suggestion would be putting the instruction sequence in a .s file,
>> rather than hardcoding the instruction encodings here, and writing the
>> code to read from the sequence as assembled by the assemble
Richard Guenther wrote on 25/07/2011 05:54:28
PM:
> From: Richard Guenther
> To: Razya Ladelsky/Haifa/IBM@IBMIL
> Cc: gcc-patches@gcc.gnu.org, Zdenek Dvorak
> , Sebastian Pop
> Date: 25/07/2011 05:54 PM
> Subject: Re: [patch] Fix PR tree-optimization/49471
>
> On Mon, Jul 25, 2011 at 4:47 PM
This fixes PR49840 - make sure to properly treat integers as wide
as a double-int correctly in range_fits_type_p.
Bootstrapped and tested on i686-linux-gnu, applied to trunk.
Richard.
2011-07-26 Richard Guenther
PR tree-optimization/49840
* tree-vrp.c (range_fits_type_p): Pr
On Mon, Jul 25, 2011 at 11:09 PM, Uros Bizjak wrote:
> Attached patch implements -fpic handling for x32. In x32 mode, we now
> use x86_64_general_operand and corresponding "e" constraints for adds
> in SImode, since it looks that invalid addresses can only be generated
> through a
> Hi,
>
> the issue in PR 49786 has been well summarized in comment #12.
> Basically, the multiplication we do when updating counts of edges
> overflows. I looked at how this was handled previously in IPA-CP and
> the following should be an equivalent solution.
>
> This patch fixes the LTO profi
Hi,
the issue in PR 49786 has been well summarized in comment #12.
Basically, the multiplication we do when updating counts of edges
overflows. I looked at how this was handled previously in IPA-CP and
the following should be an equivalent solution.
This patch fixes the LTO profiled bootstrap an
Georg-Johann Lay wrote:
> I found that too painful, and on devices with >= 8k flash the
> self-tail-call will just save 4 bytes.
That' not correct: even on devices >= 8k an rcall will always reach
the destination, so that the self tail-call always saves 6 bytes.
Johann
Hi,
another simple fix for an ICE on invalid. Tested x86_64-linux.
Ok?
Thanks,
Paolo.
/cp
2011-07-26 Paolo Carlini
PR c++/49776
* typeck.c (cp_build_modify_expr): Check digest_init return value
for error_mark_node.
/testsuite
2011-07-26 Pa
1 - 100 of 120 matches
Mail list logo
