On Wed, Dec 7, 2011 at 11:32 PM, Teresa Johnson wrote:
>>> An issue turned up in our internal 4.6 based testing that has been
>>> fixed on trunk. This patch backports the fix to 4.6. I also have a
>>> small test case that I will add to both 4.6 and 4.7.
>>>
>>> Bootstrapped and checked with x86_6
On Wed, Dec 7, 2011 at 5:07 PM, Han Shen wrote:
> + /* Examine each basic block for address taking of local variables. */
I don't think you need to look at the basic blocks to figure out if a
local variable has its address taken. You can look through referenced
variables and see if it is a loca
Hi, this patch provides a new stack protection option -
"fstack-protector-strong".
Background - some times stack-protector is too-simple while stack-protector-all
over-kills, for example, to build one of our core systems, we forcibly add
"-fstack-protector-all" to all compile commands, which br
OK.
Jason
On Wed, Dec 7, 2011 at 4:25 PM, Andrew Pinski wrote:
> On Wed, Dec 7, 2011 at 4:01 PM, Xinliang David Li wrote:
>> Build the test case in the patch file with -finstrument-functions, the
>> link will fail with unsat. The problem is gcc instruments the
>> artificial wrappers that will won't be emit
On Wed, Dec 7, 2011 at 4:01 PM, Xinliang David Li wrote:
> Build the test case in the patch file with -finstrument-functions, the
> link will fail with unsat. The problem is gcc instruments the
> artificial wrappers that will won't be emitted. The patch fixes the
> problem. Bootstrap and tested on
Build the test case in the patch file with -finstrument-functions, the
link will fail with unsat. The problem is gcc instruments the
artificial wrappers that will won't be emitted. The patch fixes the
problem. Bootstrap and tested on x86-64/linux.
Ok for mainline?
thanks,
David
Index: gimplify.c
> * include/bits/atomic_base.h (__calculate_memory_order):
> Rename to... (__cmpexch_failure_order): This, and rewrite as
> constexpr function. (compare_exchange_strong, compare_exchange_weak):
> Use it.
> * include/std/atomic (compare_exchange_strong,
> compare_exchange_weak): Lik
Hi,
The problem here is Cavium's octeon assembler rejects floating point
if the arch is set to either octeon or octeon2. This fixes the issue
by adding:
.set mips4 so that floating point instructions are enabled.
Committed as approved by Anthony in the bugzilla.
Thanks,
Andrew Pinski
libffi/C
On Wed, Dec 7, 2011 at 2:12 PM, Uros Bizjak wrote:
> Hello!
>
>> An issue turned up in our internal 4.6 based testing that has been
>> fixed on trunk. This patch backports the fix to 4.6. I also have a
>> small test case that I will add to both 4.6 and 4.7.
>>
>> Bootstrapped and checked with x86_
Hello!
> An issue turned up in our internal 4.6 based testing that has been
> fixed on trunk. This patch backports the fix to 4.6. I also have a
> small test case that I will add to both 4.6 and 4.7.
>
> Bootstrapped and checked with x86_64-unknown-linux-gnu.
>
> 2011-12-07 Teresa Johnson
>
>
An issue turned up in our internal 4.6 based testing that has been
fixed on trunk. This patch backports the fix to 4.6. I also have a
small test case that I will add to both 4.6 and 4.7.
Bootstrapped and checked with x86_64-unknown-linux-gnu.
Can someone review?
Thanks,
Teresa
2011-12-07 Teres
On 12/07/2011 12:20 PM, Jakub Jelinek wrote:
> PR bootstrap/50237
> * internal.h (_cpp_init_lexer): New prototype.
> * init.c (init_library): Call it.
> * lex.c (init_vectorized_lexer): Remove constructor attribute,
> add inline keyword.
> (HAVE_init_vectorized_l
On Wednesday 07 December 2011 14:53:20 Tobias Burnus wrote:
> ** PING **
>
> On 11/29/2011 07:35 PM, Tobias Burnus wrote:
> > gfortran had an ICE when trying to insert a check whether the
> > character length between actual and dummy argument matches. This check
> > is pointless for deferred-lengt
Hi!
By my reading auto is not valid on non-static data members, if they aren't
NSDMI, then we'd error on them (but differently between templates and
non-templates), but with NSDMI in template we just ICE because init is
DEFAULT_ARG.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for tr
On 07/12/11 16:25, Richard Earnshaw wrote:
2011-12-06 Andrew Stubbs
gcc/
* config/arm/arm.md (one_cmpldi2): Rename to ...
(one_cmpldi2_core): ... this, and modify it to prevent it being
used for NEON.
(one_cmpldi2): New define_expand.
* config/arm
OK.
Jason
On 12/07/2011 03:25 PM, Jakub Jelinek wrote:
Hi!
We already error out on .foo = style designators for arrays, but for
[N] = style designators for classes we'd just ICE.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
OK.
The last one is a accepts-invalid even for C. Jas
Hi!
This testcase regressed recently when Paolo added the user friendlier
invalid use of member function vs. invalid use of member distinction,
when TREE_OPERAND (value, 1) is BASELINK, DECL_FUNCTION_MEMBER_P on it
dies with a checking ICE.
The following patch calls get_first_fn if it is overloade
Hi!
We already error out on .foo = style designators for arrays, but for
[N] = style designators for classes we'd just ICE.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
We still have a bunch of accepts-invalid, no idea how to solve them,
because reshape_init_r is called of
Hi!
While this isn't real fix for this PR, which should be fixed in configury,
I think avoiding ctors in host code is useful for portability and Eric
agreed with that in the PR.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-12-07 Jakub Jelinek
PR bootstrap
On Friday 02 December 2011 22:01:19 Tobias Burnus wrote:
> Found via Reinhold Bader's test suite: If a component is public, it
> remains public even if the extended type has PRIVATE.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
OK.
Mikael
On Wednesday 07 December 2011 14:54:36 Tobias Burnus wrote:
> * ping * ?
>
> On 12/04/2011 06:46 PM, Tobias Burnus wrote:
> > Hi all,
> >
> > as Dominique has found, Fortran 2008 allows the BOZ edit descriptors
> > now also with REAL and COMPLEX arguments. (See PR for quotes from the
> > standard
Attached patch applied:
2011-12-07 François Dumont
PR libstdc++/51386
* include/bits/hashtable_policy.h
(_Prime_rehash_policy::_M_next_bkt):
Fix computation of _M_prev_resize so that hashtable do not keep on
being rehashed when _M_max_load_factor is lower than
On Wednesday 07 December 2011 17:45:52 Tobias Burnus wrote:
> This fixes a -frealloc-lhs regression where the RHS is handled by a
> "conversion function" whose argument has component refs.
>
> Build and regtested on x86-64-linux.
> OK for the trunk and 4.7?
>
> Tobias
OK.
Mikael
On Tue, Dec 6, 2011 at 6:28 PM, Andrew Pinski wrote:
> Hi,
> This patch adds -march=octeon+ to GCC.
> OK? Bootstrapped and tested on mips64-linux-gnu configured with
> --with-arch=octeon+ .
>
> Thanks,
> Andrew Pinski
>
> gcc/ChangeLog:
> * mips/mips-cpus.def (octeon+): New CPU.
> * config/mips/m
On Wed, Dec 7, 2011 at 7:58 PM, Iain Sandoe
wrote:
>>> Currently we are failing...
>>>
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
>>> simulation test
>>> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread
>>> simulation test
>>> FAIL: gcc.dg/simulate-thre
On 7 Dec 2011, at 18:47, Uros Bizjak wrote:
On Wed, Dec 7, 2011 at 7:43 PM, Jack Howarth
wrote:
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread
simulation test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread
simulation test
On 12/06/2011 08:32 PM, Steve Kargl wrote:
On Mon, Dec 05, 2011 at 07:21:59PM +0100, Toon Moene wrote:
2011-12-05 Toon Moene
PR/51310
invoke.texi: Itemize the cases for which -finit- doesn't
work.
OK for trunk ? (and perhaps later for the 4.6 branch ?
Looks good
On Wed, Dec 7, 2011 at 7:43 PM, Jack Howarth wrote:
> Currently we are failing...
>
> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
> test
> FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread simulation
> test
> FAIL: gcc.dg/simulate-thread/atomic-lo
Currently we are failing...
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O1 -g thread simulation
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O2 -g thread simulation
test
FAIL: gcc.dg/simulate-thread/atomic-load-int128.c -O3 -g thread simulation
test
FAIL: gcc.dg/simulate
ok for google/main.
David
On Wed, Dec 7, 2011 at 3:04 AM, wrote:
> On 2011/12/05 17:05:17, dvyukov wrote:
>>
>> This is for google-main branch.
>> Fix taking address of SSA_NAME in ThreadSanitizer pass.
>
>
>> Index: gcc/tree-tsan.c
>> ===
Applied, thanks.
Jason
This fixes a -frealloc-lhs regression where the RHS is handled by a
"conversion function" whose argument has component refs.
Build and regtested on x86-64-linux.
OK for the trunk and 4.7?
Tobias
2011-12-07 Tobias Burnus
PR fortran/51448
* fortran/trans-array.c (get_std_lbound): Fix handli
On 05/12/11 10:42, Richard Earnshaw wrote:
> On 04/12/11 13:32, kazu_hir...@mentor.com wrote:
>> Hi,
>>
>> Attached is a patch to fix miscompilation in
>> arm.md:*minmax_arithsi.
>>
>> The following testcase, reduced from efgcvt_r.c:fcvt_r in glibc, gets
>> miscompiled:
>>
>> extern void abort (voi
On 01/12/11 11:09, Georg-Johann Lay wrote:
> Richard Earnshaw wrote:
>> On 29/11/11 09:42, Matthew Gretton-Dann wrote:
>>> All,
>>>
>>> Whilst developing the Cortex-A15 integer pipeline patch it was noted
>>> that the MD_INCLUDES variable in config/arm/t-arm has not been kept
>>> up-to-date.
>>>
On Wed, Dec 07, 2011 at 04:16:25PM +, Joseph S. Myers wrote:
> On Wed, 7 Dec 2011, Richard Guenther wrote:
>
> > code - well, that's ok. Pointing people to the latest official
> > release series (in this case 4.6.x) is also ok, we're keeping too
> > many branches active IMNSHO.
>
> As I reca
On 06/12/11 17:59, Andrew Stubbs wrote:
> This patch adds a one's complement pattern for doing DImode 'not' in
> NEON registers.
>
> There are already patterns for doing one's complement of vectors, and
> even though it boils down to the same instruction, the DImode case was
> missing.
>
> The
On Wed, Dec 7, 2011 at 11:16, Richard Guenther wrote:
> I'm going to apply it tomorrow, when full testing hopefully finished
Sure. But remember the zombie kitties!
Diego.
, if
> you find adding a little function too strenuous, I guess it's not too big a
> deal.
Testing this kind of patches turns out to be quite time-consuming
(I do a LTO bootstrap and two SPEC 2k6 builds (-g and -g0)), so
yeah ...
The following is what I ended up LTO
On Wed, 7 Dec 2011, Richard Guenther wrote:
> code - well, that's ok. Pointing people to the latest official
> release series (in this case 4.6.x) is also ok, we're keeping too
> many branches active IMNSHO.
As I recall we agreed in London that both 4.3 and 4.4 should be closed
(after a final r
On 12/07/11 10:54, Richard Guenther wrote:
On Wed, 7 Dec 2011, Diego Novillo wrote:
On 12/07/11 10:46, Richard Guenther wrote:
On Wed, 7 Dec 2011, Diego Novillo wrote:
On 12/07/11 09:52, Richard Guenther wrote:
Index: gcc/lto-streamer-out.c
=
On Wed, 7 Dec 2011, Diego Novillo wrote:
> On 12/07/11 10:46, Richard Guenther wrote:
> > On Wed, 7 Dec 2011, Diego Novillo wrote:
> >
> > > On 12/07/11 09:52, Richard Guenther wrote:
> > >
> > > > Index: gcc/lto-streamer-out.c
> > > >
On 12/07/11 10:46, Richard Guenther wrote:
On Wed, 7 Dec 2011, Diego Novillo wrote:
On 12/07/11 09:52, Richard Guenther wrote:
Index: gcc/lto-streamer-out.c
===
*** gcc/lto-streamer-out.c (revision 182081)
--- gcc/lto-stream
On Wed, 7 Dec 2011, Diego Novillo wrote:
> On 12/07/11 09:52, Richard Guenther wrote:
>
> > Index: gcc/lto-streamer-out.c
> > ===
> > *** gcc/lto-streamer-out.c (revision 182081)
> > --- gcc/lto-streamer-out.c (working copy)
> > **
On 12/07/11 09:52, Richard Guenther wrote:
Index: gcc/lto-streamer-out.c
===
*** gcc/lto-streamer-out.c (revision 182081)
--- gcc/lto-streamer-out.c (working copy)
*** tree_is_indexable (tree t)
*** 129,134 ***
This letter contains second separate patch for ddg.c
It prevents removing some edges in data dependency graph
when renaming is allowed.
2011/10/12 Ayal Zaks :
>>> The other bug happens only with -fmodulo-sched-allow-regmoves. Here we
>>> eliminate some anti-dependence edges in data dependency gra
Apologies for the messed up previous e-mails.
This letter contains the first separate patch for ddg.c
It creates additional nessesary anti-dep edges in data dependency graph.
2011/10/12 Ayal Zaks :
>>> The following situation happens when SMS is enabled without register
>>> renaming
>>> (-fno-mo
On 12/07/2011 10:18 AM, Jakub Jelinek wrote:
On Wed, Dec 07, 2011 at 10:10:08AM -0500, Jason Merrill wrote:
On 12/06/2011 02:48 PM, Jakub Jelinek wrote:
- gcc_assert (!processing_template_decl || SCALAR_TYPE_P (type));
+ gcc_assert (!processing_template_decl
+ || (SCALAR_TYPE_P (t
On Wed, Dec 07, 2011 at 10:10:08AM -0500, Jason Merrill wrote:
> On 12/06/2011 02:48 PM, Jakub Jelinek wrote:
> >- gcc_assert (!processing_template_decl || SCALAR_TYPE_P (type));
> >+ gcc_assert (!processing_template_decl
> >+ || (SCALAR_TYPE_P (type) || TREE_CODE (type) == ARRAY_TYPE));
On Wed, 7 Dec 2011, Jakub Jelinek wrote:
> On Wed, Dec 07, 2011 at 03:52:35PM +0100, Richard Guenther wrote:
> > *** gcc/testsuite/gcc.dg/guality/pr48437.c (revision 0)
> > --- gcc/testsuite/gcc.dg/guality/pr48437.c (revision 0)
> > ***
> > *** 0
> > --- 1,15
> > + /* PR lt
On Wed, Dec 07, 2011 at 03:52:35PM +0100, Richard Guenther wrote:
> *** gcc/testsuite/gcc.dg/guality/pr48437.c(revision 0)
> --- gcc/testsuite/gcc.dg/guality/pr48437.c(revision 0)
> ***
> *** 0
> --- 1,15
> + /* PR lto/48437 */
> + /* { dg-do run } */
> + /* { dg-optio
On 12/06/2011 02:48 PM, Jakub Jelinek wrote:
- gcc_assert (!processing_template_decl || SCALAR_TYPE_P (type));
+ gcc_assert (!processing_template_decl
+ || (SCALAR_TYPE_P (type) || TREE_CODE (type) == ARRAY_TYPE));
How about SCALAR_TYPE_P (strip_array_types (type))? OK with that
Apologies for the messed up previous e-mail.
This letter contains the first separate patch for ddg.cIt creates
additional nessesary anti-dep edges in data dependency graph.
2011/10/12 Ayal Zaks :>>> The following situation
happens when SMS is enabled without register renaming>>>
(-fno-modulo-sched
On Wed, Dec 7, 2011 at 3:32 PM, Eric Botcazou wrote:
>> You are basically (but non-optimally) locally re-implementing
>> what expr.c:get_object_or_type_alignment does, for the
>> bare MEM_REF case (you don't consider offsets that
>> do not change the alignment, nor alignment information
>> present
: Exclude block-local
extern declarations.
* gcc.dg/lto/20111207-2_0.c: New testcase.
* gcc.dg/guality/pr48437.c: Likewise.
Index: gcc/lto-streamer-out.c
===
*** gcc/lto-streamer-out.c (revision 182081)
--
This letter contains the first separate patch for ddg.cIt creates
additional nessesary anti-dep edges in data dependency graph.
2011/10/12 Ayal Zaks :>>> The following situation
happens when SMS is enabled without register renaming>>>
(-fno-modulo-sched-allow-regmoves). When data dependency graph
Apologies for the messed up previous e-mail.
2011/10/12 Ayal Zaks :
>>> - the last jump instruction should look like: pc=(regF!=0)?label:pc, regF
>>> is
>
> you'd probably want to bump to next instruction if falling through,
> e.g., pc=(regF!=0)?label:pc+4
>
It is considered that program counte
On Wed 07 Dec 2011 14:20:43 GMT, Richard Earnshaw wrote:
Would it not require an unspec to prevent 'clever things' happening to
the negative shift, if we were to encode these in the machine
description? I'm not too clear on what these 'clever things' might be in
the case of shift-by-register (pre
2011/10/12 Ayal Zaks :>>> - the last jump
instruction should look like: pc=(regF!=0)?label:pc, regF is>> you'd
probably want to bump to next instruction if falling through,> e.g.,
pc=(regF!=0)?label:pc+4>
It is considered that program counter is increased automatically
onhardware level.Otherwise w
> You are basically (but non-optimally) locally re-implementing
> what expr.c:get_object_or_type_alignment does, for the
> bare MEM_REF case (you don't consider offsets that
> do not change the alignment, nor alignment information
> present on the SSA name).
Adjusted version attached, regression-t
On 07/12/11 14:03, Andrew Stubbs wrote:
> On Wed 07 Dec 2011 13:42:37 GMT, Richard Earnshaw wrote:
>> So it looks like the code generated for core registers with thumb2 is
>> pretty rubbish (no real surprise there -- to get the best code you need
>> to make use of the fact that on ARM a shift by a
Having a value in the wrong mode is not the only hazard that users of
set_unique_reg_note should anticipate; it could also be that the value
is computed as a constant by the compiler, and thus the last instruction
obtained with get_last_insn is completely (or somewhat) unrelated; or an
expander co
On Wed 07 Dec 2011 13:42:37 GMT, Richard Earnshaw wrote:
So it looks like the code generated for core registers with thumb2 is
pretty rubbish (no real surprise there -- to get the best code you need
to make use of the fact that on ARM a shift by a small negative number
(< -128) will give zero.
On Wed, Dec 7, 2011 at 2:32 PM, Richard Earnshaw wrote:
> On 07/12/11 13:02, Richard Guenther wrote:
>> On Wed, Dec 7, 2011 at 1:34 PM, Jakub Jelinek wrote:
>>> On Tue, Nov 29, 2011 at 05:59:53PM -0800, Doug Kwan wrote:
This is a backport for two upstream patches into our 4.6 branch.
>>>
* ping * ?
On 12/04/2011 06:46 PM, Tobias Burnus wrote:
Hi all,
as Dominique has found, Fortran 2008 allows the BOZ edit descriptors
now also with REAL and COMPLEX arguments. (See PR for quotes from the
standard.)
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
PS: Thank you
** PING **
On 11/30/2011 07:19 PM, Tobias Burnus wrote:
The bug has been introduced when changing the warning system to do
more in the front end. The problem is that for:
module m
contains
function f()
end
end
the sym->attr.referenced gets set - and no warning is printed. I now
i
** PING **
On 11/29/2011 07:35 PM, Tobias Burnus wrote:
gfortran had an ICE when trying to insert a check whether the
character length between actual and dummy argument matches. This check
is pointless for deferred-length character arguments - thus, no bounds
check should be generated.
Build
Which got fixed on trunk.
Tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-12-07 Richard Guenther
PR lto/48100
* gcc.dg/lto/20111207-1_0.c: New testcase.
* gcc.dg/lto/20111207-1_1.c: Likewise.
* gcc.dg/lto/20111207-1_2.c: Likewise.
* gcc.dg
On 02/12/11 12:42, Andrew Stubbs wrote:
> Hi All,
>
> I'm trying to implement DImode shifts using ARM NEON instructions. This
> wouldn't be difficult in itself, but making it play nice with the
> existing implementation is causing me problems. I'd like a few
> suggestions/pointers/comments to h
On 07/12/11 13:02, Richard Guenther wrote:
> On Wed, Dec 7, 2011 at 1:34 PM, Jakub Jelinek wrote:
>> On Tue, Nov 29, 2011 at 05:59:53PM -0800, Doug Kwan wrote:
>>> This is a backport for two upstream patches into our 4.6 branch.
>>> I submitted the first patch by Julian a while ago for backpor
On 2011.12.04 at 18:35 +, Nathan Sidwell wrote:
> I've committed this patch to break apart the gcov finalization routines, I
> believe this will make it easier to fix the problem shown up by bug 51113 --
> although this patch does not. Notable changes:
>
> * rename coverage_begin_output to
On 06/12/11 14:25, Michael Matz wrote:
> Hi,
>
> On Tue, 6 Dec 2011, Tom de Vries wrote:
>
>> what should be the 'next' returned by delete_insn?
>
> There are exactly two calls of delete_insn that take the return value.
> One (delete_insn_and_edges) just uses it to return it itself (and there
On Wed, Dec 7, 2011 at 1:34 PM, Jakub Jelinek wrote:
> On Tue, Nov 29, 2011 at 05:59:53PM -0800, Doug Kwan wrote:
>> This is a backport for two upstream patches into our 4.6 branch.
>> I submitted the first patch by Julian a while ago for backport but
>> Richard Earnshaw pointed out a problem
> You are basically (but non-optimally) locally re-implementing
> what expr.c:get_object_or_type_alignment does, for the
> bare MEM_REF case (you don't consider offsets that
> do not change the alignment, nor alignment information
> present on the SSA name).
Gosh. And now I distinctly remember su
On Tue, Nov 29, 2011 at 05:59:53PM -0800, Doug Kwan wrote:
> This is a backport for two upstream patches into our 4.6 branch.
> I submitted the first patch by Julian a while ago for backport but
> Richard Earnshaw pointed out a problem with the first patch. The second
> patch from Joey fixes t
On Wed, Dec 7, 2011 at 11:27 AM, Michael Zolotukhin
wrote:
> Thanks, Richard.
> Should somebody else approve the patch or is it ok for commit to trunk?
It's ok to commit.
Richard.
> On 5 December 2011 18:04, Richard Guenther wrote:
>> On Mon, Dec 5, 2011 at 2:28 PM, Michael Zolotukhin
>> wrot
On Tue, Dec 6, 2011 at 11:24 PM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on mainline and 4.6 branch at -O for the SPARC.
> The compiler generates an unaligned access for the memcpy call in:
>
> char *s
>
> union
> {
> int32_t i;
> char a[sizeof (int32_t)];
> }
> v;
>
In principle, test case pr45830.c works for target avr, but there is an issue
with the -ftree-switch-conversion optimization activated at higher optimization
levels: It transforms code size into .data usage and thus exceeds AVRs' RAM
size because of big CSWTCH lookup tables located in RAM.
The pat
On Wed, 7 Dec 2011, Jan Hubicka wrote:
> Am Tue 06 Dec 2011 03:41:36 PM CET schrieb Richard Guenther
> :
>
> >
> > This removes accounting for the number of remaining calls in
> > the inlining edge badness calculation (as discussed in private
> > with Honza a long time ago - and yes, we disagree
Friendly pinging this patch.
--- Begin Message ---
Dodji Seketeli writes:
> Jason Merrill writes:
>
>> I guess let's check DECL_ORIGINAL_TYPE instead of TREE_TYPE for alias
>> templates.
>
> Like the below that I am currently bootstrapping?
Finally this is what passed bootstrap and testing on
Georg-Johann Lay wrote:
> Denis Chertykov wrote:
>
> The only question that remains is what the -m64 option should be like?
>
> [ ] Omit it altogether
> [ ] Leave it as is (off per default)
> [ ] Set it on per default
>
> As soon as the direction is clear, I'll post a f
Am Tue 06 Dec 2011 03:41:36 PM CET schrieb Richard Guenther
:
This removes accounting for the number of remaining calls in
the inlining edge badness calculation (as discussed in private
with Honza a long time ago - and yes, we disagreed). This
Well, the main reason for disagreement was tha
Thanks, Richard.
Should somebody else approve the patch or is it ok for commit to trunk?
On 5 December 2011 18:04, Richard Guenther wrote:
> On Mon, Dec 5, 2011 at 2:28 PM, Michael Zolotukhin
> wrote:
>>> I'd just duplicate the tests you want to change to a larger array
>>> size and change those
Mike Frysinger writes:
> Building newer libiberty for s390x targets fails with relocation errors:
> libiberty/pic/libiberty.a(hashtab.o): In function 'htab_create':
> libiberty/hashtab.c:408:(.text+0x5e4): relocation truncated to fit:
> R_390_GOT12 against symbol 'xcallo
On 06/12/11 23:07, Richard Henderson wrote:
On 12/06/2011 01:42 PM, Andrew Stubbs wrote:
On Tue 06 Dec 2011 21:05:30 GMT, Richard Henderson wrote:
On 12/06/2011 09:59 AM, Andrew Stubbs wrote:
+(define_insn "*one_cmpldi2_neon"
+ [(set (match_operand:DI 0 "s_register_operand" "=w,?&r,?&r,?w
86 matches
Mail list logo
