> This has been filed as radar #10302855, but we need a work-around
> until that is resolved (possibly forever on older systems).
>
> OK for trunk?
> (what opinion about 4.6?)
Did you apply it to the 4.6 branch? I think that this would be appropriate.
> ada:
>
> PR target/50678
> * i
From: Richard Henderson
The conversion of the __sync post-reload splitters was half
complete. Since there are nearly no restrictions on what may
appear between LL and SC, expand all the patterns immediatly.
This allows significantly easier code generation for subword
atomic operations.
---
gcc/
From: Richard Henderson
---
libgcc/config/rs6000/linux-unwind.h |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/libgcc/config/rs6000/linux-unwind.h
b/libgcc/config/rs6000/linux-unwind.h
index 2011632..13bf413 100644
--- a/libgcc/config/rs6000/linux-unwind.h
+++ b/libgc
Well, most of it.
The first patch removes two avoidable warnings in rs6000.md.
It seems like we could avoid many more of the remaining, but
those are harder; this one was obvious.
The second patch is a build error. It has appeared on this
list previously, but not yet applied.
The third implemen
From: Richard Henderson
---
gcc/config/rs6000/rs6000.md |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/rs6000/rs6000.md b/gcc/config/rs6000/rs6000.md
index 331aa79..93b0b6c 100644
--- a/gcc/config/rs6000/rs6000.md
+++ b/gcc/config/rs6000/rs6000.md
@@ -6787
Richard Henderson wrote:
> These are the targets that used external __sync calls in gcc 4.6.
> I've been intending to test them myself, but since these aren't
> bare *-elf targets, it's taking me some time to get the various
> cross-environment set up.
>
> Port maintainers, please test.
SH patch
Hi David,
I couldn't imagine such breakage... If too many platforms break perhaps we
should undo the optimisation - see attached patch.
Thanks,
Dimitris
P.S. see also bug #51094 I've attached some more fixes
=== modified file 'gcc/config/elfos.h'
--- gcc/config/elfos.h 2011-10-30 01:45:46
Hi,
The current x32 implementation uses LEAs to convert 32bit address to
64bit. However, we can use addr32 prefix to use 32bit address directly.
It improves performance by 5% in SPEC CPU 2K/2006. All changes are done
in x86 backend, except for a smaill unwind library assert change:
http://gcc.g
Any ELF target that overrides ASM_GENERATE_INTERNAL_LABEL is at risk
of not building any more due to the recent elfos.h changes.
Those changes require that the label format generated by
ASM_GENERATE_INTERNAL_LABEL and TARGET_ASM_INTERNAL_LABEL are in sync,
but that is only being ensured for targe
Cc: Kaz Kojima
---
gcc/config/sh/linux.h |4
gcc/config/sh/sh.c|8
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/gcc/config/sh/linux.h b/gcc/config/sh/linux.h
index edfd99b..7a75341 100644
--- a/gcc/config/sh/linux.h
+++ b/gcc/config/sh/linux.h
@@ -131,
Cc: Richard Earnshaw
Cc: Ramana Radhakrishnan
---
gcc/config/arm/arm.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 6ef6f62..abf8ce1 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -1096,6 +1096,10 @
Cc: John David Anglin
---
gcc/config/pa/pa-linux.h |3 +++
gcc/config/pa/pa.c |3 +++
gcc/config/pa/pa.h |5 +
3 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/gcc/config/pa/pa-linux.h b/gcc/config/pa/pa-linux.h
index 6c6cf21..addc0e1 100644
--- a/gcc/co
Cc: Richard Sandiford
---
gcc/config/mips/mips.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index ff72e28..75e73bd 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -11218,9 +11218,13 @@ mips_in
These are the targets that used external __sync calls in gcc 4.6.
I've been intending to test them myself, but since these aren't
bare *-elf targets, it's taking me some time to get the various
cross-environment set up.
Port maintainers, please test.
r~
Richard Henderson (4):
arm: Install __
From: Eric Botcazou
Date: Fri, 11 Nov 2011 11:05:06 +0100
>> One thing that really irks me is how pseudo's can only be subreg'd
>> on UNITS_PER_WORD boundaries. That's the real reason this stuff
>> doesn't work and it's nearly impossible to subreg 32-bit values
>> that end up in float regs on sp
On Fri, 2011-11-11 at 12:45 -0500, Andrew MacLeod wrote:
> On 11/11/2011 12:43 AM, Benjamin Kosnik wrote:
> >
> >> bkoz: As relates to the existing problem, how is the legacy support
> >> invoked in compatibility-atomic-c++0x.cc? That has the old style
> >> implementation of atomic_flag with a loc
On 11/11/2011 09:44 AM, Uros Bizjak wrote:
> 2011-11-11 Uros Bizjak
>
> * lib/gcc-simulate-thread.exp (simulate-thread): Do not run on
> alpha*-*-linux* targets.
Ok.
r~
On Nov 11, 2011, at 12:26 PM, Iain Sandoe wrote:
> This probably qualifies as obvious - but having discussed some of the
> background with Mike ..
> .. there are other ways of solving the problem - although probably rather
> heavy-weight for this problem.
>
> .. So, I'll let him have the say...
As another step toward multiplexing goroutines onto OS threads, this
patch adopts the g variable used in the other Go's compiler runtime
support library. g is a thread-local global which holds
goroutine-specific information, as opposed to the existing thread-local
global m which holds thread-speci
This probably qualifies as obvious - but having discussed some of the
background with Mike ..
.. there are other ways of solving the problem - although probably
rather heavy-weight for this problem.
.. So, I'll let him have the say...
OK for trunk?
Iain
testsuite:
PR testsuite/5105
On 11 Nov 2011, at 14:33, Rainer Orth wrote:
Iain Sandoe writes:
however, most of the suite fails on darwin9 - with an undefined
reference
to delete(void*).
Could this be the same issue I've been seeing on Tru64 UNIX, i.e. lack
of weakdef support?
http://gcc.gnu.org/ml/gcc-patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/11 02:24, Andrey Belevantsev wrote:
> On 10.11.2011 21:31, Jeff Law wrote:
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>>
>>
>> [ This should have gone out some time ago... Sorry for the long
>> delay ]
>>
>> I'm pleased to announce t
> From: Hans-Peter Nilsson
> Date: Thu, 10 Nov 2011 18:52:39 +0100
> > From: Hans-Peter Nilsson
> > Date: Thu, 10 Nov 2011 15:12:54 +0100
>
> > > From: Bernd Schmidt
> > > Date: Thu, 10 Nov 2011 14:29:04 +0100
> >
> > > HP, can you run full tests?
> >
> > Cross-test to cris-elf in progress.
> From: Andrew MacLeod
> Date: Fri, 11 Nov 2011 18:45:11 +0100
> On 11/11/2011 12:43 AM, Benjamin Kosnik wrote:
> I think there is also an argument for single threaded-ness vs multi
> threaded. If there is no atomic support and its single threaded, we
> don't really need the lock... and I'm no
Hi,
I am working on 32bit Pmode for x32:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50797
It removes all LEAs, which convert 32bit address to 64bit, and uses 0x67
address prefix instead. I got 5% speed up in SPEC CPU 2K/2006.
But assert in _Unwind_SetGRValue:
gcc_assert (dwarf_reg_size_table
> From: Benjamin Kosnik
> Date: Fri, 11 Nov 2011 06:43:29 +0100
> So, all:
>
> config/cpu/*/atomicity.h
And config/cpu/*/atomic_word.h presumably?
> Should go. I'll look in to peeling off this cruft sharpish.
brgds, H-P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/11 00:53, Jakub Jelinek wrote:
>
> I've actually committed it yesterday after discussion with Richi on
> IRC.
No problem.
> While his patch optimizes it, it doesn't do so for -O0
Funny, I almost make this argument for accepting your patch,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 13:28, Kai Tietz wrote:
> Sure. A more general question, which was raised by Richi here.
> For BC optimization it is of course interesting to know real
> instruction-costs and not just guessings. The current code in
> fold-const guess
On Nov 11, 2011, at 12:25 AM, Iain Sandoe wrote:
> FWIW your example doesn't reproduce the problem because it contains no
> objective c exceptions code.
Ah, but it can be seen to contradict what you said. It also found a bug.
> However, OK - I see your point (I also see where the problem came f
On Nov 11, 2011, at 2:32 AM, Iain Sandoe wrote:
> This corrects a mistake I made when splitting the runtime code up - which
> causes the GNU eh personality routine to be specified for NeXT ABI 0&1.
> OK for trunk/4.6?
Ok.
With the __sync builtins, we weren't able to implement the raw loads
and stores efficiently. But with the __atomic builtins we can.
Tested on x86_64-linux and committed.
r~
* gimple-pretty-print.c (dump_gimple_omp_atomic_load): Dump needed.
(dump_gimple_omp_atomic_store): Likewi
On Fri, Nov 11, 2011 at 8:21 AM, Iyer, Balaji V wrote:
> Forgot to mention.. this is the 4th and final patch in this sequence.
>
> Thanks,
>
> Balaji V. Iyer.
>
> From: Iyer, Balaji V
> Sent: Friday, November 11, 2011 11:16 AM
> To: gcc-patches@gcc.gnu.org
> Subject: Re: [Gcc.amd] [Patch 001] [x86 backend] Define march/mtune for
> upcoming AMD Bulldozer procesor.
>
> > Hello!
> >
> > > This patch defines -march=bdver1 and -mtune=bdver1 flag for the upcoming
> > > AMD Bulldozer processor.
> Hi,
> it seems that bdver/btver is not mentioned in invoke.t
> Subject: Re: [Gcc.amd] [Patch 001] [x86 backend] Define march/mtune for
> upcoming AMD Bulldozer procesor.
>
> > Hello!
> >
> > > This patch defines -march=bdver1 and -mtune=bdver1 flag for the upcoming
> > > AMD Bulldozer processor.
> Hi,
> it seems that bdver/btver is not mentioned in invoke.t
Hi!
This fixes stdarg-2.c failures on i?86-linux, bootstrapped/regtested
on i686-linux, will commit as obvious tonight.
2011-11-11 Jakub Jelinek
PR tree-optimization/51091
* tree-stdarg.c (execute_optimize_stdarg): Ignore TREE_CLOBBER_P
rhs also in the va_list_simple_p
On 11/11/2011 12:43 AM, Benjamin Kosnik wrote:
bkoz: As relates to the existing problem, how is the legacy support
invoked in compatibility-atomic-c++0x.cc? That has the old style
implementation of atomic_flag with a lock, which would allow this
target to compile... which is another option pe
Hello!
For some reason, single-stepping executable between ldl_l and stl_c
insns in gdb [1] breaks LL/SC chaining, so atomic operations never
finish. This calls for gdb bugreport.
Also taking into account that dejagnu timeout didn't trigger for
unattended testsuite run and considering huge amount
On Fri, Nov 11, 2011 at 03:24:45PM +0100, Tobias Burnus wrote:
>
> The patch does the same we do for nonstatic variables: It allocates a
> single byte in this case; as it is done in the front-end and as it is a
> compile-time constant, there is no performance problem ;-)
What about memory press
On 11 November 2011 19:06, Jakub Jelinek wrote:
> On Fri, Nov 11, 2011 at 06:57:58PM +0200, Ira Rosen wrote:
>> On 11 November 2011 17:32, Jakub Jelinek wrote:
>> > 2011-11-11 Jakub Jelinek
>> >
>> >PR tree-optimization/51058
>> >* tree-vect-slp.c (vect_remove_slp_scalar_calls)
> > I just realized I may be feeding you an inconsistent
> > configuration, see the atomicity stuff in
> > libstdc++-v3/config/cpu/cris. Is that just obsolete and unused
> > now or what do I need to add for that to work?
> >
>
> You don't need to do anything there. I think that atomicity stuff
>
Hi,
On Fri, 11 Nov 2011, Ulrich Weigand wrote:
> I haven't fully debugged it yet, but it seems to be related to the
> linked list of unwind contexts that are maintained by the SjLj logic.
> During unwinding, those are pulled off the list one by one; it seems the
> routines that do that don't
Michael Matz wrote:
> On Fri, 11 Nov 2011, Ulrich Weigand wrote:
>
> > One reason why this happens is that the unwind*.c files are specifically
> > built with -fexception. I think this is for the benefit of the DWARF
> > unwinder, to ensure CFI records are available for those routines.
>
> Exc
On Fri, Nov 11, 2011 at 06:06:18PM +0100, Jakub Jelinek wrote:
> > Please add
> > ! { dg-final { cleanup-tree-dump "vect" } }
> >
> > OK otherwise.
>
> This is not a /vect/ testcase, but fortran torture. I guess
> if you really want I could move it over to gfortran.dg/vect/ instead,
> then the !
On Fri, Nov 11, 2011 at 06:57:58PM +0200, Ira Rosen wrote:
> On 11 November 2011 17:32, Jakub Jelinek wrote:
> > 2011-11-11 Jakub Jelinek
> >
> > PR tree-optimization/51058
> > * tree-vect-slp.c (vect_remove_slp_scalar_calls): New function.
> > (vect_schedule_slp): Call it.
On 11 November 2011 17:32, Jakub Jelinek wrote:
> Hi!
Hi,
>
> Removing the scalar call in vectorizable_call for SLP vectorization
> is too early, when another SLP instance refers to the same scalar call,
> we'll ICE because that stmt doesn't have bb anymore or gsi_for_stmt
> doesn't succeed for
On 11/11/2011 08:41 AM, Jakub Jelinek wrote:
> On Fri, Nov 11, 2011 at 08:36:36AM -0800, Richard Henderson wrote:
>> Ok, except
>>
>>> +elts[i]
>>> + = fold_convert (TREE_TYPE (TREE_TYPE (arg)), integer_zero_node);
>>
>> build_int_cst.
>
> That would work for integer modes only, but here
Hi,
On Fri, 11 Nov 2011, Ulrich Weigand wrote:
> One reason why this happens is that the unwind*.c files are specifically
> built with -fexception. I think this is for the benefit of the DWARF
> unwinder, to ensure CFI records are available for those routines.
Except for the routines that sta
Rainer Orth wrote:
> "Ulrich Weigand" writes:
> > Shouldn't the variable still be called LIB2FUNCS_EXCLUDE after the
> > move to libgcc? LIB2ADD seems to expect full file names ...
>
> Of course, the change is bogus. I can only (half) explain this by the
> change from LIB2FUNCS_STATIC_EXTRA to
Hello!
2011-11-11 Uros Bizjak
* config/alpha/elf.h (ELF_ASCII_ESCAPES): Rename from ESCAPES.
(ELF_STRING_LIMIT): Rename from STRING_LIMIT.
Tested on alphaev68-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: elf.h
=
On Fri, Nov 11, 2011 at 08:36:36AM -0800, Richard Henderson wrote:
> Ok, except
>
> > +elts[i]
> > + = fold_convert (TREE_TYPE (TREE_TYPE (arg)), integer_zero_node);
>
> build_int_cst.
That would work for integer modes only, but here the type can be REAL_TYPE
too. I think fold_convert
Paolo Bonzini writes:
> On 11/11/2011 05:23 PM, Rainer Orth wrote:
>> The trivial patch allowed a x86_64-unknown-linux-gnu x spu-elf cross to
>> finish the libgcc build, and at least the set of objects built before my
>> patch series is identical to the set built now.
>>
>> Ok for mainline?
>
> O
On 11/11/2011 07:24 AM, Jakub Jelinek wrote:
> PR tree-optimization/51074
> * fold-const.c (vec_cst_ctor_to_array, fold_vec_perm): New functions.
> (fold_binary_loc): Handle VEC_EXTRACT_EVEN_EXPR,
> VEC_EXTRACT_ODD_EXPR, VEC_INTERLEAVE_HIGH_EXPR and
> VEC_INTERLEAVE_LO
> 2011-11-07 Bin Cheng
>
> PR rtl-optimization/50663
> * cprop.c (bb_implicit): New global variable.
> (insert_set_in_table): Add additional parameter, record implicit set
> info.
> (hash_scan_set): Add additional parameter.
> (compute_hash_table_work): And
>
While reviewing PR rtl-opt/50663, I ran into some minor issues in cprop.c that
can easily be addressed:
- a few outdated comments,
- non-obvious naming of variables (pavloc, absaltered),
- reversed naming (transp instead of kill in compute_local_properties),
- inconsistent protoytype for c
Hi,
committed the patch below as obvious.
2011-11-11 Janne Blomqvist
PR libfortran/51090
* runtime/main.c (find_addr2line): NULL check before proceeding.
Index: main.c
===
--- main.c (revision 181287)
+++ ma
On 10/31/11 14:24, Henderson, Stuart wrote:
>> 2011-09-26 Jakub Jelinek
>>
>> * rtl.h (const_tiny_rtx): Change into array of 4 x MAX_MACHINE_MODE
>> from 3 x MAX_MACHINE_MODE.
>> (CONSTM1_RTX): Define.
>> * emit-rtl.c (const_tiny_rtx): Change into array of 4 x
>> MAX_MAC
On 11/11/2011 05:23 PM, Rainer Orth wrote:
The trivial patch allowed a x86_64-unknown-linux-gnu x spu-elf cross to
finish the libgcc build, and at least the set of objects built before my
patch series is identical to the set built now.
Ok for mainline?
Ok. Have you checked for other occurrenc
"Ulrich Weigand" writes:
> Rainer Orth wrote:
>
>> diff --git a/gcc/config/spu/t-spu-elf b/gcc/config/spu/t-spu-elf
>
>> -# We exclude those because the libgcc2.c default versions do not support
>> -# the SPU single-precision format (round towards zero). We provide our
>> -# own versions below a
On 11/11/11 16:30, Joey Ye wrote:
> -fstrict-volatile-bitfields doesn't work incorrectly in some cases
> when storing into a volatile bit-field.
>
> Bernd provided a fix here about 1 year ago:
> http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html.
> But it is pending to trunk. Here are my hu
Forgot to mention.. this is the 4th and final patch in this sequence.
Thanks,
Balaji V. Iyer.
From: Iyer, Balaji V
Sent: Friday, November 11, 2011 11:16 AM
To: gcc-patches@gcc.gnu.org
Subject: [PATCH][Cilkplus] Patch to fix unused variable
Hello Everyone,
Hello Everyone,
This patch is for the Cilkplus branch affecting both C and C++ compilers.
This patch will fix an unused variable warning in collect2.c by enclosing the
variable inside #ifdef TARGET_AIX_VERSION.
Thanks,
Balaji V. Iyer.diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
inde
Hello Everyone,
This patch is for the Cilkplus branch, affecting both C and C++ compilers.
This patch will remove the CILKPLUS_IMPLEMENTED macro and all the #ifdef and
#ifndef that uses it.
This is patch #3.
Thanks,
Balaji V. Iyer.diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
ind
Hello Everyone,
This patch is for the Cilkplus branch, affecting the C and C++ compilers.
This patch will fix a warning about converting a const void * to tree.
This patch is PATCH #2.
Thanks,
Balaji V. Iyer.diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index 285f059..511d8f7
On 11/11/2011 04:42 AM, Dodji Seketeli wrote:
Fabien Chêne a écrit:
Are the other debugging backends not interested at all in USING_DECLs ?
The way debug info is generated for USING_DECLs is that
handle_using_decl (via cp_emit_debug_info_for_using) asks the backend to
generate debug info for
Hello Everyone,
This patch is for the Cilk Plus branch, mainly affecting the G++
compiler. This patch will add the extra parameter (enum call_context) into
finish_call_expr that was added in the weekly merge.
I am planning to send approximately 4 patches today, and so please
com
On Fri, Nov 11, 2011 at 4:33 PM, Jakub Jelinek wrote:
> The avx-vzeroupper-14.c testcase now fails, because normal epilogue isn't
> emitted and before simple_return or return we forgot to emit the vzeroupper
> insn. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
> ok for tr
Michael Matz wrote:
> * gimplify.c (gimplify_bind_expr): Add clobbers for all variables
> that go out of scope and live in memory.
This seems to have completely broken SPU exception handling (note that
SPU is currently completely broken anyway due to the libgcc move).
What happens is
Hi!
The avx-vzeroupper-14.c testcase now fails, because normal epilogue isn't
emitted and before simple_return or return we forgot to emit the vzeroupper
insn. Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux,
ok for trunk?
2011-11-11 Jakub Jelinek
* config/i386/i3
Hi!
Removing the scalar call in vectorizable_call for SLP vectorization
is too early, when another SLP instance refers to the same scalar call,
we'll ICE because that stmt doesn't have bb anymore or gsi_for_stmt
doesn't succeed for it.
Fixed by postponing replacement of calls with zeroing of lhs
Hi!
On Thu, Nov 10, 2011 at 12:00:53PM -0800, Richard Henderson wrote:
> VEC_PERM_EXPR is explicitly modulo. Don't fail, mask.
Here is an updated patch.
In addition to the creation of subroutines this performs the permutation
folding using an unsigned char array for selector and folds VEC_PERM_
Hi,
the problem in PR 50605 is that is_gimple_ip_invariant returns false
for
&MEM[(struct tRecorderImp *)&recorder + 8B]
where &reorder is an IP gimple invariant. This patch fixes that by
copying the code that handles MEM_REFs from
is_gimple_invariant_address (and only changing
decl_address_i
Iain Sandoe writes:
> however, most of the suite fails on darwin9 - with an undefined reference
> to delete(void*).
Could this be the same issue I've been seeing on Tru64 UNIX, i.e. lack
of weakdef support?
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01426.html
At least my weakdef.c t
Dear all,
attached one patches for issues found by Joel when testing gfortran on
RTEMS.
Coarrays with -fcoarray=lib: For zero-sized static ("save") coarray
arrays, we should allocate a single byte rather than 0 bytes as "ptr =
malloc (0)" might return either NULL or a unique pointer. If it
An update .. in case anyone is following...
On 11 Nov 2011, at 00:21, Richard Henderson wrote:
On 11/10/2011 03:29 PM, Iain Sandoe wrote:
The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup
FAOD, Is there some reason that this library needs to resolve symbols
from some exter
Hi,
On Thu, 10 Nov 2011, Steve Ellcey wrote:
> This patch (r181172) has broken my bootstrap of IA64 Linux and I am
> trying to figure out what to do about it.
>
> The failure happens while building libunwind (I did not configure with
> --with-system-libunwind):
>
> /ctires/gcc/nightly/build-ia6
Hi,
On Fri, Nov 04, 2011 at 08:01:41AM -0700, Delesley Hutchins wrote:
> Thanks for the suggestion. Unfortunately, knowing the original
> declaration doesn't help me; I also need to know the original
> arguments that were passed at the call site, before those arguments
> were removed by ipa-sra.
This corrects a mistake I made when splitting the runtime code up -
which causes the GNU eh personality routine to be specified for NeXT
ABI 0&1.
This causes a linkage error if "-fexceptions" is specified for NeXT @
m32
(although there's no functional effect, since there is no ZCE
impleme
> I have already signed copyright agreement with the FSF. Will I need
> the separate one for this particular commit?
No, if your contributions are already covered by a copyright agreement with the
FSF, nothing more needs to be done.
--
Eric Botcazou
> Eric, I tried my best to get the new code working properly on 64-bit
> and I just couldn't figure out a reasonably way to do so.
Same here, this looks really tricky. On the one hand we could give in a little
and tolerate inferior code quality in 64-bit mode, but on the other hand this
is a bi
Hello Eric,
2011/11/11 Eric Botcazou :
>> Great! I'll be back with patch covering all non functional changes.
>> Will it be OK to have everything in one patch (including current
>> functional changes) or I should split it?
>
> Let's also rename the file while we are at it. I'd suggest Redundant
Fabien Chêne a écrit:
> Are the other debugging backends not interested at all in USING_DECLs ?
The way debug info is generated for USING_DECLs is that
handle_using_decl (via cp_emit_debug_info_for_using) asks the backend to
generate debug info for the DECLs the USING_DECL resolves to, basically
> Great! I'll be back with patch covering all non functional changes.
> Will it be OK to have everything in one patch (including current
> functional changes) or I should split it?
Let's also rename the file while we are at it. I'd suggest Redundant Extension
Elimination for the name of the pass
On 10.11.2011 21:31, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[ This should have gone out some time ago... Sorry for the long delay ]
I'm pleased to announce that the GCC steering committee has approved
the nomination of Andrey Belevantsev, Alexander Monakov, and Dmitry
M
Eric, I tried my best to get the new code working properly on 64-bit
and I just couldn't figure out a reasonably way to do so.
Therefore I simply reverted the changes. I'll come back to this at
some point in the future.
One thing that really irks me is how pseudo's can only be subreg'd
on UNITS
2011/11/10 Dodji Seketeli :
> Fabien Chêne a écrit:
>
>> Index: gcc/dbxout.c
>> ===
>> --- gcc/dbxout.c (revision 178088)
>> +++ gcc/dbxout.c (working copy)
>> @@ -1518,6 +1518,8 @@ dbxout_type_fields (tree type)
>> i
On 11 Nov 2011, at 00:30, Mike Stump wrote:
On Nov 10, 2011, at 9:40 AM, Iain Sandoe wrote:
Thanks for catching that --- brainstorm on my part ... the code
under discussion should have been #ifndef OBCPLUS
There is no prohibition against C having exceptions, so, doesn't
matter if you turn
86 matches
Mail list logo
