_sp32): Reindent constraints.
(movtf_insn_sp32_no_fpu): Likewise.
(movtf_insn_sp64): Likewise.
(movtf_insn_sp64_hq): Likewise.
(movtf_insn_sp64_no_fpu): Likewise.
2011-11-02 Eric Botcazou
* gcc.target/sparc/20111102-1.c: New test.
--
Eric Botcazou
I'm checking in this variant of your patch; mostly it just adds
-Wno-narrowing to the warning options used to build GCC, though there
are a few wording tweaks as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 6b5380306428a3e618027b3fc7a319ae2c520b35
Author: Jason Merrill
Date: T
And a few more diagnostic tweaks:
commit 2839df54ee49e6ba454d3ad842bc0018f3b29162
Author: Jason Merrill
Date: Wed Nov 2 15:01:37 2011 -0400
* parser.c (cp_parser_decl_specifier_seq): Change "C++0x" to
"C++11" in warnings.
(cp_lexer_get_preprocessor_token): Likewise.
(cp_pa
> From: Rainer Orth
> Date: Wed, 2 Nov 2011 13:37:33 +0100
> Rainer Orth writes:
>
> > The next patch in the series moves crtstuff.c, extra_parts, EXTRA_PARTS,
> > EXTRA_MULTILIB_PARTS and referenced files to libgcc. This will avoid
> > errors due to inconsistencies in extra_parts between gcc
From: Eric Botcazou
Date: Wed, 2 Nov 2011 21:07:15 +0100
> This is a fallout of the consolidation patch for floating-point insns. When
> the regular and no_fpu patterns for movdf were merged, the r/ro alternative
> of
> the latter pattern was merged with the r/rFo alternative of the former.
> From: Anatoly Sokolov
> Date: Wed, 2 Nov 2011 20:37:12 +0100
> As subject suggests.
>
> Regression tested on cris-axis-elf.
>
> Comments?
Thanks, I'll review this once the tree returns to single-digit
regression state.
brgds, H-P
On 10/19/2011 05:33 PM, Richard Guenther wrote:
> On Wed, Oct 19, 2011 at 10:23 AM, Tom de Vries wrote:
>> Richard,
>>
>> For the example from the PR, -ftree-tail-merge discovers that blocks 6 and 7
>> are
>> equal, removes block 7 and redirects the outgoing edge of it's predecessor
>> block
>>
From: Eric Botcazou
Date: Wed, 2 Nov 2011 13:29:45 +0100
> This has reintroduced PR target/49965.
I am working on fixing this right now, thanks for reporting Eric.
Hi!
- Gather vectorization patch + incremental patches
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02411.html
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02846.html
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg02851.html
Jakub
On Wed, 2 Nov 2011, Ian Lance Taylor wrote:
> David Daney writes:
>
> > On MIPS we fail because of those. I was going to create a patch to
> > move those two to libcall_linux_{386,amd64}.go. An alternative would
> > be to remove them too.
>
> Moving them sounds good to me. libgo already has
On Wed, 2 Nov 2011, David Daney wrote:
> On Linux you also have iopl and ioperm which are x86 only.
ARM and Alpha appear to have them as well, though I don't know if anyone
actually uses them on those targets.
--
Joseph S. Myers
jos...@codesourcery.com
On 11/02/11 21:13, Hans-Peter Nilsson wrote:
> For big changes such as this, please test on a cross
> configuration as well.
>
> For cris-elf, a patch in the range 180770:180778 supposedly
> yours, cause massive testsuite failures on the form of not
> finding functions in libgcc at link-time. Fro
On 11/02/2011 09:11 PM, Jason Merrill wrote:
I'm checking in this variant of your patch; mostly it just adds
-Wno-narrowing to the warning options used to build GCC, though there
are a few wording tweaks as well.
Tested x86_64-pc-linux-gnu, applying to trunk.
Thanks!
Paolo.
Hi all,
at the GSoC Mentor summit, I had a chat with Joel, who asked me whether
he should try to crosscompile also Fortran. Well, at the end I created
the attached patch (based on what one had to do for libquadmath) and he
successfully build fortran to target RTEMS for i386, sparc64, powerpc,
I'm backporting this so that, if we run into a particularly obnoxious
set of narrowing conversions in the C++11 transition, we can just
-Wno-narrowing instead of rolling a new gcc release.
Tested with check-c++ on ubuntu x86_64. Since this is going into a
google branch, I'll just commit it in a fe
My sparc-linux-gnu builds with --enable-targets=all is failing with:
../../../../gcc/libgcc/config/sparc/lb1spc.S: Assembler messages:
../../../../gcc/libgcc/config/sparc/lb1spc.S:124: Error: detected global
register use not covered by .register pseudo-op
../../../../gcc/libgcc/config/sparc/lb1s
On Wed, Nov 2, 2011 at 5:57 PM, Jagasia, Harsha wrote:
>> >> > > We would like to propose changing AVX generic mode tuning to
>> >> generate
>> >> > 128-bit
>> >> > > AVX instead of 256-bit AVX.
>> >> >
>> >> > You indicate a 3% reduction on bulldozer with avx256.
>> >> > How does avx128 compare t
This patch fixes an ICE caused when the ipa-sra optimization deletes
function arguments that are referenced from within a thread safety
attribute. It will attempt to detect this situation and recover
gracefully. Since a graceful recovery is not always possible, an
optional warning (-Wwarn-thread-
Bootstrap on a PPC target fails quickly due to some missing backslashes
in this file.
Applying to trunk.
commit b6263426a342d87fd94314c58d914a9f57b818e5
Author: Jason Merrill
Date: Wed Nov 2 16:35:09 2011 -0400
* config/rs6000/t-ppccomm: Add missing \.
diff --git a/libgcc/config/rs6000
On Wed, Nov 2, 2011 at 22:25, Tobias Burnus wrote:
> Hi all,
>
> at the GSoC Mentor summit, I had a chat with Joel, who asked me whether he
> should try to crosscompile also Fortran. Well, at the end I created the
> attached patch (based on what one had to do for libquadmath) and he
> successfully
2011/10/27 Jason Merrill :
[...]
>> 3) seems complicated: in finish_member_declaration, we must put away
>> the decl into TYPE_FIELDS or TYPE_METHODS, but we would like to put
>> the target_decl into TYPE_METHODS (and call add_method), and at the
>> same time put its using decl into TYPE_FIELDS...
This broke bootstrap on powerpc64-unknown-linux-gnu, due to a couple of
problems with t-ppccomm. I fixed the missing backslashes, but the
startup file recipes are clearly wrong as well:
ecrti$(objext): $(srcdir)/config/rs6000/eabi-ci.S
$(crt_compile) -c ecrti.S
Note that they try to c
C++11 list-initialization doesn't involve a second copy constructor
call, even copy-list-initialization. We were building one incorrectly,
which causes problems if the copy ctor is deleted.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0b34e91f284e47ac4e9240954d10242c9feb6e61
Author: J
On 11/02/2011 03:36 PM, David Miller wrote:
My sparc-linux-gnu builds with --enable-targets=all is failing with:
../../../../gcc/libgcc/config/sparc/lb1spc.S: Assembler messages:
../../../../gcc/libgcc/config/sparc/lb1spc.S:124: Error: detected global
register use not covered by .register pseud
On Wed, Sep 28, 2011 at 11:21 AM, Ian Lance Taylor wrote:
> On Mon, Sep 19, 2011 at 5:52 PM, Doug Evans wrote:
>>
>> 2011-09-19 Doug Evans
>>
>> include/
>> * timeval-utils.h: New file.
>>
>> libiberty/
>> * timeval-utils.c: New file.
>> * Makefile.in (CFILES
On 2 Nov 2011, at 19:39, Peter Bergner wrote:
On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
I'm going to try this
char name[32];
- get_ppc64_thunk_name (name);
+ get_ppc476_thunk_name (name);
This (together with the changes for HAVE_GAS_HIDD
Uros Bizjak writes:
> http, rpc and websocket tests that fail previously [1] now run OK, but
> there are a bunch of new failures:
Doesn't look too bad, really. Thanks for testing.
If you feel like debugging the failures, you can do it by changing
directory to TARGET/libgo and running
make GOT
Hi all,
the attached patch does a little cleanup: It occurred to me recently
that 'gfc_extend_expr' has an argument 'real_error', which is a bit
awkward. Its function would be better encoded in an enhanced range of
return values. What the patch does is to change the return value from
'gfc_try' (SU
From: Joel Sherrill
Date: Wed, 2 Nov 2011 16:29:16 -0500
> Is this similar to what I just got for sparc-rtems when compiling
> libgcc2 with -mcpu=v8?
>
> /tmp/cczMc4jN.s: Assembler messages:
> /tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for
> "smul".
> /tmp/cczMc4jN.s:18:
From: David Miller
Date: Wed, 02 Nov 2011 18:30:56 -0400 (EDT)
> From: Joel Sherrill
> Date: Wed, 2 Nov 2011 16:29:16 -0500
>
>> Is this similar to what I just got for sparc-rtems when compiling
>> libgcc2 with -mcpu=v8?
>>
>> /tmp/cczMc4jN.s: Assembler messages:
>> /tmp/cczMc4jN.s:16: Error:
newlib has a configure check that works by running readelf on a target
binary. While a native readelf is generally pretty generic and
cross-friendly, it's possible for a build host not to have any readelf at
all. It's clearly the right thing that configure use a target readelf tool
if there is on
On Wed, Nov 2, 2011 at 11:17 PM, Janus Weil wrote:
> What the patch does is to change the return value from
> 'gfc_try' (SUCCESS/FAILURE) to 'match'
> (MATCH_YES/MATCH_NO/MATCH_ERROR). Of course we're not really
> 'matching' anything here, but the yes/no/error range of values is
> exactly what we
2011/11/2 Steven Bosscher :
> On Wed, Nov 2, 2011 at 11:17 PM, Janus Weil wrote:
>> What the patch does is to change the return value from
>> 'gfc_try' (SUCCESS/FAILURE) to 'match'
>> (MATCH_YES/MATCH_NO/MATCH_ERROR). Of course we're not really
>> 'matching' anything here, but the yes/no/error ran
Hi,
[Eric, see below for an Ada issue]
so, this is a more complete resubmission of an old patch, trying to get it
into 4.7. In order not to have to rely on TREE_BLOCK of variables to
determine valid sharing (which never really worked that well when all the
intermediate code movements that cou
From: David Miller
Date: Wed, 02 Nov 2011 18:43:52 -0400 (EDT)
> So t-softmul gets appended anyways, and this causes us to try and
> build config/sparc/lb1spc.S for the 64-bit libgcc which we should
> never do.
I tried the patch below but it just results in syntax errors in the
Makefile.
Is thi
On Wed, Nov 2, 2011 at 4:28 PM, David Miller wrote:
> +LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
> + = x../lib64; then echo sparc/lb1spc.S; fi`
> +LIB1ASMFUNCS = `if test x$$($(CC) -print-multi-os-directory) \
> + = x../lib64; then ech
On Thu, Nov 03, 2011 at 12:06:23AM +0100, Janus Weil wrote:
> 2011/11/2 Steven Bosscher :
> > On Wed, Nov 2, 2011 at 11:17 PM, Janus Weil wrote:
> >> What the patch does is to change the return value from
> >> 'gfc_try' (SUCCESS/FAILURE) to 'match'
> >> (MATCH_YES/MATCH_NO/MATCH_ERROR). Of course
> Wouldn't some tools behave better if the asm files had ELF
> decorations on the functions?
If you mean .type and .size, I added those.
On Wed, 2 Nov 2011, David Miller wrote:
> Actually the problem is that libgcc/config.host checks ${host}
> to decide whether to append config/sparc/t-softmul to the tmake
> variable.
${host} is the *target* when configuring target libraries.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, 2 Nov 2011, David Miller wrote:
> Is this the way differences between multilib cases are going to be
> handled now in libgcc, with these backtick shell conditionals that (of
> all things) looks at the destination directory?
>
> What if I want to put 64-bit libraries in a different locatio
> > - unsigned int __max_iter = 100;
> > + unsigned int __max_iter = 65536U;
>
> Doesn't that need to be 65535U for your purpose?
Yup. The other three did.
> Should have the runtime license exception.
Added.
> This should not be needed; just using t-fdpbit should suffice for
>
> This is unnecessary with my just applied series of libgcc patches:
> it's the default for all *-*-elf targets.
Moving targets! Fixed.
> This is not only unnecessary, as Joseph already noted, but doesn't
> work for quite some time since fp-bit.c has been moved to libgcc.
Fixed.
> Ah. All validity issues aside, then "Dereferencing unaligned
> pointers yields a compile-time error" or "pointers with unknown
> alignment" would be much less cryptic: the "Dereferencing -1"
> just sounds like *(char *) -1 or a cut
I put a more explanatory comment in there.
I'm not exactly su
> And there's also one issue with Ada that I need help with: it doesn't
> build anymore. ;-) Well, the tools don't link when C++ bootstrap is
> active. This is because our whole libbackend is compiled with g++, and
> hence uses the gxx_personality_v0 routines. But the gnattools are linked
> with
From: Andrew Pinski
Date: Wed, 2 Nov 2011 16:40:13 -0700
> On Wed, Nov 2, 2011 at 4:28 PM, David Miller wrote:
>> +LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
>> + = x../lib64; then echo sparc/lb1spc.S; fi`
>> +LIB1ASMFUNCS = `if test x$$($(CC) -print-multi
From: "Joseph S. Myers"
Date: Thu, 3 Nov 2011 00:22:49 + (UTC)
> On Wed, 2 Nov 2011, David Miller wrote:
>
>> Actually the problem is that libgcc/config.host checks ${host}
>> to decide whether to append config/sparc/t-softmul to the tmake
>> variable.
>
> ${host} is the *target* when confi
On Wed, 2 Nov 2011, David Miller wrote:
> > ${host} is the *target* when configuring target libraries.
>
> It doesn't represent the 'target' we're generating code for in
> a multilib instance so we can conditionalize off of it correctly.
>
> The only way sparc/t-softfp can be added to tmake is i
I have merged trunk->cxx-mem-model once again, so I can generate a
master diff to post to the list for the curious. And so we can make
sure there are no spurious changes unrelated to the branch.
I have bootstrapped the toolchain, and have run some preliminary tests
on simulate-thread.exp. Ev
Hi,
this issue seems pretty easy to deal with: submitter complains that we
warn for
void foo(int* p);
void bar() {
foo(false);
}
and we do *not* for:
void foo(int* p);
void bar() {
const bool kDebugMode = false;
foo(kDebugMode);
}
thus I tried using decl_constant_var_p / integral_co
I found this with the rl78-elf port... can't guarantee it's not the
rl78 port itself, but the code does have two loops that fill the
array.
* caller-save.c (setup_save_areas): Increase call_saved_regs[]
size to avoid writing beyond the end of the array. There are
two loo
GCC assumes the target has a multiply insn, but better code is
generated using shifts if it doesn't (vs a libcall). Found with the
rl78-elf port.
* expr.c (expand_expr_real_2): Don't try to emit a MUL-based
expression if the target doesn't have a multiply pattern. Fall
b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This was caught by some prototype code to warn for potential NULL
pointer dereferences.
Let's look at vt_equate_reg_base_value from alias.c:
void
vt_equate_reg_base_value (const_rtx reg1, const_rtx reg2)
{
VEC_replace (rtx, reg_base_value, REGNO
The RL78 port has 8 bit registers and 16 bit pointers. The existing
calculation resulted in a buffer that was too small for the five
values needed.
* except.c (init_eh): Fix setjmp buffer size calculations for
targets where pointers are not word-sized.
Index: gcc/except.c
==
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/02/11 21:21, DJ Delorie wrote:
> I found this with the rl78-elf port... can't guarantee it's not
> the rl78 port itself, but the code does have two loops that fill
> the array.
>
> * caller-save.c (setup_save_areas): Increase call_saved_regs[]
Roland McGrath writes:
> MAINTAINERS doesn't make it entirely clear what the procedure really is for
> touching these files. Looking at src/ChangeLog I see both what appear to
> be instances where changes were first committed to GCC and then merged over
> to src/, and instances where changes wer
On Wed, 2 Nov 2011, DJ Delorie wrote:
>
> GCC assumes the target has a multiply insn, but better code is
> generated using shifts if it doesn't (vs a libcall). Found with the
> rl78-elf port.
>
> * expr.c (expand_expr_real_2): Don't try to emit a MUL-based
> expression if the target do
On Wed, 2011-11-02 at 22:02 +, Iain Sandoe wrote:
> On 2 Nov 2011, at 19:39, Peter Bergner wrote:
>
> > On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
> >> I'm going to try this
> >> char name[32];
> >> - get_ppc64_thunk_name (name);
> >> + get
From: "Joseph S. Myers"
Date: Thu, 3 Nov 2011 01:21:35 + (UTC)
> What is new is that you can now put tests in libgcc/configure.ac
> such as the "Check 32bit or 64bit for x86." one, and select t-*
> files based on those tests - whereas in the gcc/ directory there is
> no possibility at all for
This might be valid if we knew for certain that the memory is
writable. But I don't see that we can assume that.
* optabs.c (expand_atomic_load): Don't try compare-and-swap.
---
gcc/ChangeLog.mm |6 +-
gcc/optabs.c
* builtins.c (HAVE_mem_thread_fence, gen_mem_thread_fence,
HAVE_mem_signal_fence, gen_mem_signal_fence): Default.
(expand_builtin_mem_thread_fence): Tidy.
(expand_builtin_mem_signal_fence): Fallback to asm memory barrier.
---
gcc/ChangeLog.mm |7 +++
gcc/bui
* config/i386/i386.md (UNSPEC_MOVA): New.
* config/i386/sync.md (ATOMIC): New mode iterator.
(atomic_load, atomic_store): New.
(atomic_loaddi_fpu, atomic_storedi_fpu, movdi_via_fpu): New.
---
gcc/ChangeLog.mm|7 ++
gcc/config/i386/i386.md |3 +
gcc/c
101 - 161 of 161 matches
Mail list logo
