2011/7/25 Richard Sandiford rdsandif...@googlemail.com:
Robert Millan r...@gnu.org 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
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 required:
On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
Richard Guenther wrote:
On Mon, Jul 25, 2011 at 4:23 PM, Ulrich Weigand uweig...@de.ibm.com wrote:
I had always understood this to reflect the simple fact that a
pointer to some type must never hold a value that is
On Mon, Jul 25, 2011 at 7:05 PM, DJ Delorie d...@redhat.com 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
On Mon, Jul 25, 2011 at 7:52 PM, Martin Jambor mjam...@suse.cz 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,
On Tue, Jul 26, 2011 at 12:23 AM, Richard Guenther
richard.guent...@gmail.com 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
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
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
thus the
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 maybe
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
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
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
Eric Botcazou ebotca...@adacore.com 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
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.
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
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
Robert,
2011/7/25 Richard Sandiford rdsandif...@googlemail.com:
Robert Millan r...@gnu.org 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
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 a more
Hi,
another simple fix for an ICE on invalid. Tested x86_64-linux.
Ok?
Thanks,
Paolo.
/cp
2011-07-26 Paolo Carlini paolo.carl...@oracle.com
PR c++/49776
* typeck.c (cp_build_modify_expr): Check digest_init return value
for error_mark_node.
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
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
Richard Guenther richard.guent...@gmail.com wrote on 25/07/2011 05:54:28
PM:
From: Richard Guenther richard.guent...@gmail.com
To: Razya Ladelsky/Haifa/IBM@IBMIL
Cc: gcc-patches@gcc.gnu.org, Zdenek Dvorak
rakd...@kam.mff.cuni.cz, Sebastian Pop s...@gcc.gnu.org
Date: 25/07/2011 05:54 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 assembler.
2011/7/26 Rainer Orth r...@cebitec.uni-bielefeld.de:
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
On Tue, Jul 26, 2011 at 2:59 PM, Razya Ladelsky ra...@il.ibm.com wrote:
Richard Guenther richard.guent...@gmail.com wrote on 25/07/2011 05:54:28
PM:
From: Richard Guenther richard.guent...@gmail.com
To: Razya Ladelsky/Haifa/IBM@IBMIL
Cc: gcc-patches@gcc.gnu.org, Zdenek Dvorak
Richard Guenther wrote:
On Mon, Jul 25, 2011 at 5:25 PM, Ulrich Weigand uweig...@de.ibm.com 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.
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 alignment. Or
On Tue, Jul 26, 2011 at 03:22, Richard Guenther rguent...@suse.de 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:
On Tue, 26 Jul 2011, Sebastian Pop wrote:
On Tue, Jul 26, 2011 at 03:22, Richard Guenther rguent...@suse.de 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 rguent...@suse.de 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 seb...@gmail.com 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
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
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, 2011
On Tue, 26 Jul 2011, Sebastian Pop wrote:
On Tue, Jul 26, 2011 at 09:07, Richard Guenther rguent...@suse.de 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
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 kirill.yuk...@intel.com
PR target/49547
* config/i386/abmintrin.h (head): Added check
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 hongjiu...@intel.com
PR target/49853
* config/i386/i386.c (ix86_expand_move): Call convert_to_mode
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*
H.J. Lu hjl.to...@gmail.com 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 kirill.yuk...@gmail.com wrote:
I've also prepared a bunch of tests for lzcnt instuction generation..
/ChangeLog entry:
2011-07-26 Kirill Yukhin kirill.yuk...@intel.com
* lib/target-supports.exp (check_lzcnt_hw_available): New.
Any updates/questions on this?
On 18 July 2011 15:00, Michael Zolotukhin
michael.v.zolotuk...@gmail.com 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
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 rguent...@suse.de 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
On Tue, 26 Jul 2011, Sebastian Pop wrote:
On Tue, Jul 26, 2011 at 09:33, Richard Guenther rguent...@suse.de 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
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);
+
On Tue, Jul 26, 2011 at 7:30 AM, Ian Lance Taylor i...@google.com 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
On Tue, Jul 26, 2011 at 9:46 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Jul 26, 2011 at 7:30 AM, Ian Lance Taylor i...@google.com 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.
On Tue, Jul 26, 2011 at 09:39:02AM +0200, Richard Guenther wrote:
On Mon, Jul 25, 2011 at 7:52 PM, Martin Jambor mjam...@suse.cz wrote:
...
2011-07-25 Martin Jambor mjam...@suse.cz
* tree-sra.c (tree_non_mode_aligned_mem_p): Strip conversions and
return false for
On Tue, Jul 26, 2011 at 4:59 PM, H.J. Lu hongjiu...@intel.com 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 hongjiu...@intel.com
PR target/49853
*
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 rtl
On Tue, Jul 26, 2011 at 10:26 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Jul 26, 2011 at 4:59 PM, H.J. Lu hongjiu...@intel.com 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
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 {
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 hjl.to...@gmail.com 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 hongjiu...@intel.com
PR target/49853
*
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
On Tue, Jul 26, 2011 at 10:36 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Jul 26, 2011 at 7:31 PM, H.J. Lu hjl.to...@gmail.com 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
On Tue, Jul 26, 2011 at 10:56, Sebastian Pop seb...@gmail.com wrote:
On Tue, Jul 26, 2011 at 10:43, Richard Guenther rguent...@suse.de 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
Rainer Orth wrote:
+proc check_effective_target_mmap {} {
+return [check_no_compiler_messages mmap assembly {
+ #include sys/mman.h
+}]
+}
Unfortunately, this test breaks spu-elf; a lot of tests now fail with:
loop-2f.c:(.text+0x100): undefined reference to `mmap'
The problem
Ping.
On Thu, Jul 21, 2011 at 11:20 PM, Ian Lance Taylor i...@google.com 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.
On Tue, Jul 26, 2011 at 7:50 PM, H.J. Lu hjl.to...@gmail.com 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 hongjiu...@intel.com
PR target/49853
*
On Tue, Jul 26, 2011 at 08:30, Richard Guenther
richard.guent...@gmail.com 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
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
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:
*
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
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'd
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.
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 hongjiu...@intel.com
PR target/47372
* config/i386/i386.c (ix86_delegitimize_address): Call
The patch is committed to google/main to fix lipo test regressions after trunk
merge.
2011-07-26 David Li davi...@google.com
* value-prof.c (gimple_value_profile_transformations): Remove redundant
code.
* cgraphunit.c (cgraph_mark_functions_to_output): Fix assertion in lipo
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;
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
On Tue, Jul 26, 2011 at 10:12 PM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Jul 26, 2011 at 10:05:06PM +0200, Uros Bizjak wrote:
2011-07-26 H.J. Lu hongjiu...@intel.com
PR target/47372
* config/i386/i386.c (ix86_delegitimize_address): Call
simplify_gen_subreg
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]
function_decl 0x7f6f2eaad000 __sflush)
] UNSPEC_GOTPCREL)) [2 S4 A8])
So,
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
On Tue, Jul 26, 2011 at 10:33 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Tue, Jul 26, 2011 at 1:29 PM, Jakub Jelinek ja...@redhat.com 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 [
Committed.
--
DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
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
call
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~
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
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. */
+ for (cur =
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
On Tue, Jul 26, 2011 at 16:13, Delesley Hutchins deles...@google.com 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
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
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
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
Hi,
For x32, movabs is only supported with register and constant operands.
OK for trunk?
Thanks.
H.J.
2011-07-26 H.J. Lu hongjiu...@intel.com
* config/i386/predicates.md (x86_64_movabs_operand): Don't allow
nonmemory_operand for TARGET_X32.
diff --git
Hi,
The offsetted memory references always work for x32. OK for trunk?
Thanks.
H.J.
2011-07-26 H.J. Lu hongjiu...@intel.com
PR target/49860
* config/i386/predicates.md (x86_64_immediate_operand): Always
allow the offsetted memory references for TARGET_X32.
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
91 matches
Mail list logo
