2011/7/25 Richard Sandiford :
> Robert Millan writes:
>> This patch adds support for GNU/kFreeBSD systems running on MIPS.
>
> Looks good. However, Rainer's in the middle of moving things from gcc/
> to libgcc/ -- where they belong -- and committing a new port now would
> interfere with that. If
> When last week a testcase using mmap was posted with a copy of some old
> (and wrong) list of targets supporting mmap, I noticed what mess we have
> here. To fix this, I've introduced a new effective-target keyword mmap
> and use it in all testcases.
>
> Two minor changes to the tests were requ
On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand wrote:
>> > I had always understood this to reflect the simple fact that a
>> > pointer to some type must never hold a value that is not properly
>> > aligned for th
On Mon, Jul 25, 2011 at 7:05 PM, DJ Delorie wrote:
>
>> Fact is that GCC knows that memory is not properly aligned.
>
> So in the impossibly rare case that gcc is *wrong*, how is the
> programmer supposed to tell gcc that? I mean, gcc 4.4 has been doing
> what the programmer wanted, and zillions
On Mon, Jul 25, 2011 at 7:52 PM, Martin Jambor wrote:
> Hi,
>
> On Thu, Jul 21, 2011 at 11:40:32AM +0200, Martin Jambor wrote:
>> Hi,
>>
>> On Thu, Jul 21, 2011 at 10:34:35AM +0200, Richard Guenther wrote:
>> > On Wed, 20 Jul 2011, Ulrich Weigand wrote:
>> >
>> > > Richard Guenther wrote:
>> > > >
On Tue, Jul 26, 2011 at 12:23 AM, Richard Guenther
wrote:
> Hmm. I suppose we'd need to see at the initial expand stage that the
> move is going to be handled specially. For other strict-align targets
> we end up with store/load-bit-field for unaligned accesses, so I suppose
> SPU doesn't want t
On 25/07/2011 10:46, Romain Geissler wrote:
Hello,
This iteratoc won't work because of a little typo error (the previous
edge field is preDs and not preCs).
To avoid future errors, i apply the global /precs/preds/ change (and
thus the iterator is renamed).
Romain Geissler
Hello,
I wrote the
On Mon, 25 Jul 2011, Sebastian Pop wrote:
> "Bug 47046 - gcc.target/i386/sse4_1-movntdqa.c ICEs with -fgraphite-identity"
>
> The problem here is that we are left with the following code to be
> translated in the new representation following the transform that
> Graphite has chosen:
>
>
On Tue, Jul 26, 2011 at 10:02:35AM +0200, Pierre wrote:
> On 25/07/2011 10:46, Romain Geissler wrote:
> >Hello,
> >
> >This iteratoc won't work because of a little typo error (the previous
> >edge field is preDs and not preCs).
> >To avoid future errors, i apply the global /precs/preds/ change (and
zhr...@ispras.ru writes:
> The next three describe the control part of new supported loops.
> - the last jump instruction should look like: pc=(regF!=0)?label:pc, regF is
> flag register;
> - the last instruction which sets regF should be: regF=COMPARE(regC,X), where
> X
> is a constant, or m
Hi,
This is V2 of a series of 4 patches relating to ARM atomic operations;
they incorporate most of the feedback from V1 - thanks Ramana, Richard and
Joseph for comments.
1) Provide 64 bit atomic operations using the new ldrexd/strexd in ARMv6k
and above.
2) Provide fallbacks so that w
Add ARM 64bit sync helpers for use on older ARMs. Based on 32bit
versions but with check for sufficiently new kernel version.
gcc/
* config/arm/linux-atomic-64bit.c: New (based on linux-atomic.c)
* config/arm/linux-atomic.c: Change comment to point to 64bit ve
Micahel K. Edwards points out in PR/48126 that the sync is in the wrong
place
relative to the branch target of the compare, since the load could float
up beyond the ldrex.
gcc/
* config/arm/arm.c (arm_output_sync_loop): Move label before barier,
gcc/
* config/arm/arm.c (TARGET_HAVE_DMB_MCR) MCR Not available in Thumb1
but is available on armv6
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 0d419d5..146b9ad 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -285,7 +285,8 @@ extern voi
Eric Botcazou writes:
>> gcc/ada/init.c (__gnat_install_handler) explicitly does not include
>> SA_SIGINFO in sa_flags, which means the handler only gets one arg, sig.
>> Still the installed handler (__gnat_error_handler) accesses args beyond
>> the first.
>
> Why would it get only one arg? The
Hello,
Here is updated patch for tree reassoc phase. Update includes coding
style fixes, comments update, target hook arguments change. I also
moved a part of code from rewrite_expr_tree into separate function to
reuse it in rewrite_expr_tree_parallel for grouping operands with the
same rank.
Boo
Ira,
> Could this patch be also backported to 4.6? gcc.dg/vect/pr49038.c fails on
> 4.6 as well (on SPU).
I guess so. I'd like to give it two weeks soak time on mainline before
doing so.
Rainer
--
-
Rainer Ort
> It gets three *if SA_SIGINFO is set in act.sa_flags*, which is is not.
That isn't what the comment says though:
SA_SIGINFO [...]
If cleared and the signal is caught, the first argument is
also the signal number but the second argument is the signal
code i
Robert,
> 2011/7/25 Richard Sandiford :
>> Robert Millan writes:
>>> This patch adds support for GNU/kFreeBSD systems running on MIPS.
>>
>> Looks good. However, Rainer's in the middle of moving things from gcc/
>> to libgcc/ -- where they belong -- and committing a new port now would
>> interfe
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg02186.html
Richard Henderson wrote:
> On 07/25/2011 10:30 AM, Georg-Johann Lay wrote:
>> PR target/29560
>> * config/avr/avr.md: Add peephole2 to map ashlhi3 to ashlqi3 if
>> high part of shift target is unused.
>
> Ok.
>
> r~
Here is
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
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,
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
> 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
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
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
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
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
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
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
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
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
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
Hi,
One of cp-demangle.c changes in June/July caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49852
--
H.J.
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
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 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.
>
>
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
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
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,
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?
>
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.
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_
> 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
"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
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)
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.
>
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
>
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
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
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
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, 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
"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, 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
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, 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
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 .
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
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
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
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
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 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
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 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
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 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
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
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 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
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 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 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 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
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
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
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
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
OK.
Jason
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'
+ 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
"H.J. Lu" writes:
> I checked in this as an obvious fix.
Thanks. I wonder why I didn't see that.
Ian
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
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 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 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
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
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
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
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
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
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'
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
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
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
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
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
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 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.
> >
>
1 - 100 of 120 matches
Mail list logo
