Hello,
Attached is a new version of the patch.
Thanks to Dominique Dhumieres for testing on
powerpc-apple-darwin9.
Tested ppc64-redhat-linux on with both -m32,-m64 and SPU.
OK for mainline?
Thanks,
Revital
testsuite/Changelog
PR rtl-optimization/47013
* gcc.dg/sms-2.c: Change
Document the annotalysis branch, move the thread-annotations branch
to the list of inactive branches and refer to annotalysis.
As discussed with Delesley; applied.
Gerald
Index: svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.ht
On Sat, 12 Nov 2011, Dave Anglin wrote:
>> John, Richard, while you are at it, mind making this GNU/Linux per
>> guidance from RMS? (That'll save us work later on.)
> Yes. I don't want to participate in this controversy.
That was more a rhetorical question. :-\
Addressing this is not really opt
On Mon, 21 Nov 2011, Andi Kleen wrote:
> It would be good if that could be done for 4.7. Then slim LTO
> bootstrap has a chance to work. Are there any reasons left not to
> update?
That's one reason. The FreeBSD changes (which we now get
separately) another. The GNU/Linux vs Linux fix that RMS
r
On Wed, 16 Nov 2011, Tobias Burnus wrote:
I have committed the following patch for
http://gcc.gnu.org/gcc-4.7/changes.html#fortran
How about the following minor editorial change on top?
Gerald
Index: changes.html
===
RCS file: /c
On Sun, 13 Nov 2011, Jonathan Wakely wrote:
> Would that be improved by replacing i386 with x86?
>
> libstdc++ omits several features when built for 80386 due to the lack
> of certain atomic operations, so I think it might be useful if the
> manual used x86 to refer to the generic architecture, as
And this completes the exercise for libstdc++. Fun, fun, fun.
Gerald
2011-11-27 Gerald Pfeifer
* scripts/run_doxygen (problematic): Change Linux reference to
GNU/Linux.
Index: scripts/run_doxygen
===
--- script
The last remaining instance of Linux vs GNU/Linux in the libstdc++
documentation is fixed thusly. Applied.
On the way I spotted an odd reference to GCC. Looking at the
overall document, it occurs to me that
- newer versions of GCC are not covered, and
- references to GCC generally are of t
Testing on coldfire revealed a double call to library functions for some omp
atomic calls. This was due to this function trying to return "target" for
success for unused_result. Except that for unused_result, target is null,
which indicates expansion failure. Oops.
r~
* optabs.c (ex
Testing on m68k-linux -mcpu=5206 (aka coldfire, aka no cas insn) revealed that
we hadn't properly registered __sync_val_compare_and_swap_4. Oops.
r~
* optabs.c (init_sync_libfuncs_1): Include max in iteration.
diff --git a/gcc/optabs.c b/gcc/optabs.c
index 1aafd28..0ce21e9 100644
---
The m68k-linux failure for the various omp atomic tests
is due to the fact that BIGGEST_ALIGNMENT is 16 bits on
that platform. I think it's pretty reasonable to assume
that if something is aligned to BIGGEST_ALIGNEMENT, then
it can be considered "aligned".
Tested on x86_64-linux and m68k-linux cr
On 11/26/2011 01:58 PM, Eric Botcazou wrote:
>> The first four patches simply do the conversion, a piece at a time,
>> assuming the RMO for all cpus.
>
> The new form of the membar_v8 insn looks a bit strange since operand 1 is
> disregarded. If this is as intended, a comment would be in order.
> The first four patches simply do the conversion, a piece at a time,
> assuming the RMO for all cpus.
The new form of the membar_v8 insn looks a bit strange since operand 1 is
disregarded. If this is as intended, a comment would be in order.
> The fifth patch adds the ability to explicitly set
I've applied this patch to fix issue 51297. Solaris' bsearch blows up with a
NULL array. I also noticed the possibility of passing NULL pointers to memcpy,
so took the opportunity of fixing that too. Thanks to Eric for verifying the
fix is good.
nathan
2011-11-26 Nathan Sidwell
> Being in stage 3 shouldn't stop us trying to fix bugs in the compiler:
> we're not in the final run-up to a release yet (that could still be five
> months away if history is anything to go by). It should just be a
> clamp-down on major new functionality.
But Richard's proposed change wasn't rea
On 11/25/2011 10:34 AM, Jakub Jelinek wrote:
> PR rtl-optimization/49912
> * cfgrtl.c (rtl_verify_flow_info_1): Ignore also EDGE_PRESERVE bit
> when counting n_branch.
>
> * g++.dg/other/pr49912.C: New test.
Ok.
r~
Hello!
2011-11-26 Uros Bizjak
* gcc.dg/vect/fast-math-vect-call-2.c: Require vect_double
effective target.
Tested on x86_64-pc-linux-gnu {,-m32}, committed to mainline SVN.
Uros.
Index: gcc.dg/vect/fast-math-vect-call-2.c
=
This fixes the easy bits.
PR libstdc++/51296
* testsuite/30_threads/thread/native_handle/typesizes.cc: Do not run
on alpha*-*-osf*.
* testsuite/30_threads/future/cons/constexpr.cc: Disable debug
symbols.
* testsuite/30_threads/shared_future/cons/cons
Dear all,
(First, this is *not* for the 4.6/4.7 rejects-valid regression, which is
related to intent(in) pointers with allocatable components.)
When debugging an issue with with polymorphic arrays and MOVE_ALLOC, I
got lost in the code generation of move_alloc - and didn't like the
generated
Bernd Schmidt writes:
> + CLEAR_HARD_REG_SET (set_regs);
> + note_stores (PATTERN (scan), record_hard_reg_sets,
> +&set_regs);
> + if (CALL_P (scan))
> + IOR_HARD_REG_SET (set_regs, call_used_reg_set);
> +
On Fri, Nov 25, 2011 at 8:31 PM, Uros Bizjak wrote:
> However, the patch uncovers certain problems with existing fild/fistpl
> implementation of atomic load/store. It fails in several of thread
> simulation tests, i.e.
>
> FAIL: gcc.dg/simulate-thread/atomic-load-longlong.c -O0 -g thread
> simu
With this rewrite of simplify_conversion_using_ranges we go back to the
original problem of considering if a single conversion is sufficient
considering the known input range.
Bootstrapped and regtested on i686-pc-linux-gnu.
2011-11-18 Joern Rennecke
PR tree-optimization/50802
On Sat, Nov 26, 2011 at 02:17:08AM -0500, Joern Rennecke wrote:
> 2011-11-19 Joern Rennecke
>
> PR middle-end/50074
> * calls.c (mem_overlaps_already_clobbered_arg_p):
> Return false if no outgoing arguments have been stored so far.
Ok for trunk.
> Index: calls.c
> =
gcc-patches-ow...@gcc.gnu.org wrote on 22/11/2011 03:31:22 PM:
> From: Ramana Radhakrishnan
> > gcc/testsuite/lib/
> > * target-supports.exp (check_effective_target_vect_intfloat_cvt):
True
> > for ARM NEON.
> > (check_effective_target_vect_uintfloat_cvt): Likewise.
> > (check
24 matches
Mail list logo
