* 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
* 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
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
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
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
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
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
-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[]
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
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
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
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
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 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
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
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
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
> 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
> 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
> 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.
> > - 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
>
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
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
> 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 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
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
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
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
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
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
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
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:
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:
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
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
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
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 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
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
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
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...
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
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
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-
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
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
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
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,
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.
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 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 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
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
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.
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: 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
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: 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
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
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
_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
this actually.
Paolo.
/
Index: internal.h
===
--- internal.h (revision 180785)
+++ internal.h (working copy)
@@ -739,8 +739,8 @@
static inline int ustrncmp (const unsigned char *, const unsigned char *,
On 11/02/2011 08:44 PM, Paolo Carlini wrote:
On 11/02/2011 08:12 PM, Jason Merrill wrote:
Another bootstrap issue:
In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In
function ‘unsigned char* ustrchr(const unsigned c
On Wed, Nov 2, 2011 at 5:50 PM, Ian Lance Taylor wrote:
>> #defines with arguments are not working at all. Please consider
>> following testcase:
>
> You're right: this approach doesn't work for preprocessor macros with
> arguments. Making those work via this approach would be much much
> harder
On Wed, 2011-11-02 at 14:05 -0500, Peter Bergner wrote:
> On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
> > Hmm .. I wonder if this is just a temporary glitch because of the move
> > of files to libgcc.
>
> Note that I just hit a problem with the libgcc move. We need:
>
> Index: libgcc
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 2c53423..6ce240a 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -561,10 +561,14 @@ struct processor_costs ix86_size_cost = {/* costs for
tuning for size */
COSTS_N_BYTES (2), /* cost of FAB
On 11/02/2011 08:12 PM, Jason Merrill wrote:
Another bootstrap issue:
In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In function
‘unsigned char* ustrchr(const unsigned char*, int)’:
/home/jason/src/trunk/gcc/fortran
On Wed, 2011-11-02 at 19:33 +, Iain Sandoe wrote:
> I'm going to try this
>
> $ svn diff -x -p gcc/config/rs6000/rs6000.c
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c (revision 180788)
> +++ gcc
Hello.
As subject suggests.
Regression tested on cris-axis-elf.
Comments? OK to install?
* config/cris/constraints.md: New file.
* config/cris/cris.h (REG_CLASS_FROM_LETTER, CONSTRAINT_LEN,
CRIS_CONST_OK_FOR_LETTER_P, CONST_OK_FOR_CONSTRAINT_P,
CONST_DOUBLE
On 2 Nov 2011, at 19:05, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
I'll investigate a bit further later...
So you didn't start your build from scratch? I'll keep my
fingers crossed that a fresh build fixing things for you.
Otherwise, let me know what you fin
> I am going to benchmark the following hunk separately tonight. It is
> independent change.
You would probably need some changes from sse.md (for gen_sse2_loadq).
Michael
Another bootstrap issue:
In file included from /home/jason/src/trunk/gcc/fortran/cpp.c:35:0:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h: In function
‘unsigned char* ustrchr(const unsigned char*, int)’:
/home/jason/src/trunk/gcc/fortran/../../libcpp/internal.h:782:55: error:
cast
On Wed, 2011-11-02 at 18:52 +, Iain Sandoe wrote:
> Hmm .. I wonder if this is just a temporary glitch because of the move
> of files to libgcc.
Note that I just hit a problem with the libgcc move. We need:
Index: libgcc/config/rs6000/t-ppccomm
=
Hi,
I am going to benchmark the following hunk separately tonight. It is
independent change.
Rth, Vladimir: there are obviously several options how to make GCC use SSE for
64bit loads/stores in 32bit codegen (and 128bit loads/stores in 128bit
codegen). What do you think is best variant here?
(an
Nobody has asked the obvious question: why does libssp use "*(int *)(-1)
= 0;" in the first place?
> 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
Good point.
OK for google/main with the nits below.
http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main
File ChangeLog.google-main (right):
http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main#newcode1
ChangeLog.google-main:1: 2011-11-02 Kostya Serebryany
1 2011-
On 2 Nov 2011, at 18:34, Peter Bergner wrote:
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
also in macho_branch_islands () :
if (TARGET_LINK_STACK)
{
char name[32];
get_ppc64_thunk_name (name);
strcat (tmp_buf, ":\n\tmfl
On Wed, 2 Nov 2011, DJ Delorie wrote:
> > > Index: configure.ac
> > > +# Dereferencing -1 is a compile-time error
> >
> > This (those lines) look a little cryptic (and lack punctuation ;)
> > Wild improvement guess: "Too small 'int'?".
>
> No, the compiler specifically tests for unaligned acces
On 11/02/2011 07:26 PM, Jason Merrill wrote:
On 11/02/2011 01:45 PM, Paolo Carlini wrote:
... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want
to break it again, better doing the below too. Seems obvious, by itself.
Yep.
Great, all done. Note for the accidental reader: it's in
Hi,
tested x86_64-linux, committed to mainline.
Paolo.
//
2011-11-02 Richard B. Kreckel
Paolo Carlini
PR libstdc++/50880
* include/std/complex (__complex_acosh): Fix in a better way,
use Kahan's formula.
* include/tr1/complex (__
On Wed, 2011-11-02 at 13:18 -0400, David Edelsohn wrote:
> The two new functions have mistakes because I did not realize the
> semantics of HAVE_GAS_HIDDEN. HAVE_GAS_HIDDEN is not a macro to be
> tested at runtime, but a macro tested at compile time.
I'm sorry, I didn't realize that either. Does
On Wed, 2011-11-02 at 18:17 +, Iain Sandoe wrote:
> also in macho_branch_islands () :
>
> if (TARGET_LINK_STACK)
> {
> char name[32];
> get_ppc64_thunk_name (name);
> strcat (tmp_buf, ":\n\tmflr r0\n\tbl ");
> strcat (tmp_buf, n
On 11/02/2011 01:45 PM, Paolo Carlini wrote:
... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want
to break it again, better doing the below too. Seems obvious, by itself.
Yep.
Jason
The invoke.texi change looks fine. The ChangeLog entry needs some work.
http://codereview.appspot.com/5272048/diff/41001/ChangeLog.google-main
File ChangeLog.google-main (right):
http://codereview.appspot.com/5272048/diff/41001/ChangeLog.google-main#newcode6
ChangeLog.google-main:6:
1 2011-11
On 2 Nov 2011, at 17:18, David Edelsohn wrote:
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner
wrote:
+/* Fills in the label name that should be used for a 476 link
stack thunk. */
+
+void
+get_ppc476_thunk_name (char name[32])
+{
+ gcc_assert (TARGET_LINK_STACK);
+
+ if (HAVE_GAS_HIDDE
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 a framework for
architecture specific system calls. It doe
Ian Lance Taylor writes:
> I assume that CentOS 5.5 uses some version of glibc before version 2.6.
Right:
$ /lib/libc.so.6
GNU C Library stable release version 2.5, by Roland McGrath et al.
> The three functions you mention are not supported in older versions of
> glibc. Fortunately, they ar
On 10/26/2011 10:38 AM, Richard Guenther wrote:
> On Tue, Oct 25, 2011 at 2:15 PM, Tom de Vries wrote:
>> Richard,
>>
>> I have a patch for the i686 bootstrap problem reported in PR50763 comment 10.
>>
>> pr50763-2.c looks like this before tail_merge_optimize:
>> ...
>> std_canonical_va_list_type
On 11/02/2011 10:54 AM, Ian Lance Taylor wrote:
Rainer Orth writes:
All go and libgo execution tests are failing for me with this patch on
x86_64-unknown-linux-gnu (CentOS 5.5, I think):
output is:
/var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
bgo/.libs/libg
> deduce that this path is unreachable is to generate an abort and output an
> informative notice with inform ().
Hmmm... I'll see if I can catch it early enough to do something more
meaningful, then.
> (I don't see what actually generates the error, since there are only two
Actually, it's in
Rainer Orth writes:
> All go and libgo execution tests are failing for me with this patch on
> x86_64-unknown-linux-gnu (CentOS 5.5, I think):
>
> output is:
> /var/gcc/regression/trunk/2.6.18-gcc-gas-gld/build/x86_64-unknown-linux-gnu/./li
> bgo/.libs/libgo.so: undefined reference to `inotify_in
Hi,
I tried GCC trunk to test the non static member initializer, and noticed a
bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50965
I noticed that the reason is that Some code path test if the test is an
aggregate type before running the constructors.
But in C++11 the definition of aggregate
... ehm, we use -Wcast-qual during the bootstrap, thus if I don't want
to break it again, better doing the below too. Seems obvious, by itself.
Paolo.
//
2011-11-02 Paolo Carlini
PR c++/50956
* builtins.c (fold_builtin_memchr): Fix cast.
Index: builtins.c
=
OK.
Jason
On Nov 2, 2011, at 10:17 AM, Andrew Haley wrote:
> Sure, but that doesn't answer the question, which was "is there ever
> any advantage to building in-srcdir?" The answer "Yes: one can build
> in srcdir" doesn't quite do it!
Well, unstated in that is that one doesn't have to manually create an ob
On Tue, Oct 4, 2011 at 4:57 PM, Mike Stump wrote:
> On Oct 4, 2011, at 2:37 PM, Quentin Neill wrote:
>> Ping?
>
> The problem with this patch is it reorders the listing so that lower priority
> things are after higher priority things. The entire point of the routine is
> to list the high priori
On Tue, Nov 1, 2011 at 3:00 PM, Peter Bergner wrote:
> +/* Fills in the label name that should be used for a 476 link stack thunk.
> */
> +
> +void
> +get_ppc476_thunk_name (char name[32])
> +{
> + gcc_assert (TARGET_LINK_STACK);
> +
> + if (HAVE_GAS_HIDDEN)
> + sprintf (name, "__ppc476.ge
Hi,
this should restore -Wcast-qual to the 3.4.x (!) behavior, more or less.
The diff seems large but the new code is essentially in the last 5
lines. When fixing this issue the most subtle existing testcase to get
right, IMHO, is c-c++-common/Wcast-qual-1.c. Duplicate warnings should
not be
On 11/02/2011 05:11 PM, Mike Stump wrote:
> On Nov 2, 2011, at 2:42 AM, Andrew Haley wrote:
>> On 11/01/2011 04:51 PM, Mike Stump wrote:
>>> On Nov 1, 2011, at 4:27 AM, Andrew Haley wrote:
On 10/30/2011 01:51 PM, Gerald Pfeifer wrote:
> Why not just declare
> that building from the sam
1 - 100 of 161 matches
Mail list logo
