On 11/08/2011 09:24 PM, Jeff Law wrote:
We don't have access to those assertions as they're removed well prior
to this pass running. However, if we did, or if we had redundant PHIs
in the stream which were propagated we'd be presented with something like
BB0 if (p_1) goto BB1 else goto BB2
BB
On 9 November 2011 01:05, Jonathan Wakely wrote:
> On 9 November 2011 00:56, Paolo Carlini wrote:
>> On 11/09/2011 12:51 AM, Jonathan Wakely wrote:
>>>
>>> The obvious fix is simply to change the argument type, but is there a
>>> reason it's defined that way?
>>
>> Is there any reason for not havin
Make sure to mark decl addresses coming from constructors
as addressable (otherwise early folding fails for all java testcases).
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2011-11-09 Richard Guenther
* gimple-fold.c (canonicalize_constructor_val): Mark
On Tue, Nov 8, 2011 at 6:10 PM, Xinliang David Li wrote:
> Here is the revised patch. Bootstrap and regression tested on linux/x86-64.
>
> Honza, can you comment on the implication of this change?
Jason also seems to have touched this again, so maybe it's already
fixed?
> thanks,
>
> David
>
> O
2011/11/8 Tobias Burnus :
>> I am asking the question :-) Are the two equivalent? To my mind, it
>> is a matter of taste, if they are.
>
> I think in practice they are the same.
Alright, since no one seems to have any strong preference, I'll just
go ahead and commit my version of the patch (as a
On Tue, Nov 8, 2011 at 8:35 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 15:53, Richard Guenther wrote:
>> On Mon, Nov 7, 2011 at 10:25 PM, Jakub Jelinek
>> wrote:
>>> Hi!
>>>
>>> This patch attempts to optimize VEC_BASE if we know that offsetof
>>> of bas
> From: Alan Modra
> Date: Tue, 1 Nov 2011 16:33:40 +0100
> On Tue, Nov 01, 2011 at 12:57:22AM +1030, Alan Modra wrote:
> * function.c (bb_active_p): Delete.
> (dup_block_and_redirect, active_insn_between): New functions.
> (convert_jumps_to_returns, emit_return_for_exit)
On Tue, Nov 8, 2011 at 8:47 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 15:25, Richard Guenther wrote:
>>
>> Indeed. We'd have to tell people that they cannot catch *(void *)0
>> = 0 with a SIGSEGV signal handler unless they compile with some
>> magic fla
> PS: Any chance of wrapping the long line to less than 80 characters?
Committed as rev. 181198, with the long line in intrinsic.c wrapped.
Thanks for reviewing,
FX
> Alright, since no one seems to have any strong preference, I'll just
> go ahead and commit my version of the patch (as approved by Paul).
Committed as r181199. Thanks for the comments, everyone!
Cheers,
Janus
* Iain Sandoe, 2011-11-07 :
> Subject: PING 1 [Patch Ada RFA] make sure that multilibs are built with
> correct s-oscons.ads
Patch looks fine to me.
--
Thomas Quinot, Ph.D. ** qui...@adacore.com ** Senior Software Engineer
AdaCore -- Paris, France -- New York, USA
> Although I suspect you've been lurking in the background,
> welcome back to the land of gfortran hacking. Your first
> screw up is free, additional screw ups require you to
> fix your screw up and fix an additional bug as your reward.
Attached patch committed as revision 181200.
FX
convert
> * Iain Sandoe, 2011-11-07 :
>
> > Subject: PING 1 [Patch Ada RFA] make sure that multilibs are built with
> > correct s-oscons.ads
>
> Patch looks fine to me.
It's an official 'OK' then.
When we transform an indirect to a direct call or when, with LTO,
two incompatible function declarations are merged, we can end up
with call statements that use calling conventions according to
a different function type than the type of the actual function
being called. Currently we try to make s
This fixes PR51039 - another case of mismatches with respect to
gimple_call_cannot_inline_p and gimple_check_call_matching_types.
The code in ipa-inline-analysis.c looks out-of-place and it doesn't
check for a conservative setting - thus the patch removes the
code and instead adds verification cod
Ping^2. Better support for nested if-then-else structures:
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01935.html
>
>
> Bernd
>
Hi,
apparently, in my -Wzero-as-null-pointer-constant I forgot to check the
NE_EXPR we are synthesizing upon new and delete, thus these spurious
warnings (I beefed up the original testcase to exercise the vector case
too). The fix seems largely obvious, just use nullptr_node more, but I
would
On Wed, 9 Nov 2011, Richard Guenther wrote:
>
> When we transform an indirect to a direct call or when, with LTO,
> two incompatible function declarations are merged, we can end up
> with call statements that use calling conventions according to
> a different function type than the type of the ac
On Wed, 9 Nov 2011, Richard Guenther wrote:
>
> This fixes PR51039 - another case of mismatches with respect to
> gimple_call_cannot_inline_p and gimple_check_call_matching_types.
> The code in ipa-inline-analysis.c looks out-of-place and it doesn't
> check for a conservative setting - thus the p
> I'm regtesting the patch on SH, though currently many C++ tests fail
> on SH with
>
> undefined reference to `std::atomic_thread_fence(std::memory_order)'.
There are no new failures with the patch + reverting
148018 workaround on sh4-unknown-linux-gnu.
Regards,
kaz
Hi,
looks like one of the usual cases of 'complain' not propagated enough,
in this case, from finish_class_member_access_expr to lookup_member.
Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2011-11-09 Paolo Carlini
PR c++/51047
* search.c (lookup_member):
On 11/08/2011 05:25 PM, Richard Henderson wrote:
On 11/08/2011 02:08 PM, Patrick Marlier wrote:
- change the match for g to _ITM_RU[48]
Change the match to [248].
I have never seen a "long" type to have a size of 2 bytes but I am
probably wrong. (I did not find the C specification but I fou
On Wed, 9 Nov 2011, Richard Guenther wrote:
> On Wed, 9 Nov 2011, Richard Guenther wrote:
>
> >
> > This fixes PR51039 - another case of mismatches with respect to
> > gimple_call_cannot_inline_p and gimple_check_call_matching_types.
> > The code in ipa-inline-analysis.c looks out-of-place and i
Hi!
This patch essentially reverts part of Bernd's 2011-07-06 changes,
which was IMHO wrong. As const_op here is a constant in wider mode than
MODE (which is the inner mode of the SIGN_EXTEND), the old code
(and what this patch is restoring) didn't check just that the sign bit
is clear, but also
Hi,
reportedly, the patchlet which plugged the memory leak reported in
PR36819 can cause problems when heads[QUOTE] or tails[QUOTE]. Thus I'm
finishing testing the below. Really, if we have reasons to believe that
the issue is much more complex than this, I guess we can also revert
PR36819, -
On 11/09/11 16:32, Jakub Jelinek wrote:
> --- gcc/combine.c.jj 2011-11-08 23:35:12.0 +0100
> +++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
> @@ -11397,9 +11397,12 @@ simplify_comparison (enum rtx_code code,
>later on, and then we wouldn't know whether to sign- or
>
Hi Richard,
On 8 Nov 2011, at 21:29, Richard Henderson wrote:
On 11/08/2011 01:20 PM, Iain Sandoe wrote:
is it expected for libitm to work on x86 darwin?
Yes.
hmmm...
powerpc-darwin is not affected (doesn't auto configure because there's
no powerpc directory under libitm/config).
How
On Wed, Nov 09, 2011 at 04:44:55PM +0100, Bernd Schmidt wrote:
> On 11/09/11 16:32, Jakub Jelinek wrote:
> > --- gcc/combine.c.jj2011-11-08 23:35:12.0 +0100
> > +++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
> > @@ -11397,9 +11397,12 @@ simplify_comparison (enum rtx_code co
> Eric, the testsuite target tests for vis2 and vi3 capable hardware
> work well in my own testing but if you find some problem with how
> it's done just let me know and I'll try to fix it up.
There are many failures in 64-bit mode with VIS1 because of the use of the high
part to expand vec_init,
On 11/09/11 17:24, Jakub Jelinek wrote:
> --- gcc/combine.c.jj 2011-11-08 23:35:12.0 +0100
> +++ gcc/combine.c 2011-11-09 10:06:27.20764 +0100
> @@ -11397,13 +11397,20 @@ simplify_comparison (enum rtx_code code,
>later on, and then we wouldn't know whether to sign- or
>
On 11/09/2011 08:14 AM, Iain Sandoe wrote:
> On i686-darwin9 it fails with "target only supports weak alias"
> (I need to understand better where that comes from - but the machine is tied
> up right now).
This is fixed. I removed the alias in favor of a plain function for
portability.
I also ad
On 11/09/2011 09:17 AM, Paolo Carlini wrote:
looks like one of the usual cases of 'complain' not propagated enough,
in this case, from finish_class_member_access_expr to lookup_member.
Hmm, the function already has a "protect" parameter that overlaps
somewhat with the functionality we're looki
OK.
Jason
On Wed, Nov 09, 2011 at 05:47:02PM +0100, Bernd Schmidt wrote:
> Yes, I think I prefer this.
So here is hopefully last iteration of that.
Negative constants that trunc_int_for_mode to the same value
are IMHO just fine too, similarly for ZERO_EXTEND 0x for HImode
should be fine too. On the ot
On 11/09/2011 06:09 PM, Jason Merrill wrote:
On 11/09/2011 09:17 AM, Paolo Carlini wrote:
looks like one of the usual cases of 'complain' not propagated enough,
in this case, from finish_class_member_access_expr to lookup_member.
Hmm, the function already has a "protect" parameter that overlap
On 9 Nov 2011, at 17:01, Richard Henderson wrote:
On 11/09/2011 08:14 AM, Iain Sandoe wrote:
On i686-darwin9 it fails with "target only supports weak alias"
(I need to understand better where that comes from - but the
machine is tied up right now).
This is fixed. I removed the alias in fa
On Nov 8, 2011, at 2:40 PM, Alan Modra wrote:
> On Tue, Nov 08, 2011 at 11:37:57AM +0100, Olivier Hainque wrote:
>> Joseph resorted to mem:scratch to impose a strong barrier. That's certainly
>> safe and I don't think the performance impact can be significant, so this
>> looks like a good way out
On Wed, 9 Nov 2011, Paolo Carlini wrote:
> Hi,
>
> reportedly, the patchlet which plugged the memory leak reported in PR36819 can
> cause problems when heads[QUOTE] or tails[QUOTE]. Thus I'm finishing testing
> the below. Really, if we have reasons to believe that the issue is much more
> complex
On 11/09/2011 06:21 PM, Joseph S. Myers wrote:
On Wed, 9 Nov 2011, Paolo Carlini wrote:
Hi,
reportedly, the patchlet which plugged the memory leak reported in PR36819 can
cause problems when heads[QUOTE] or tails[QUOTE]. Thus I'm finishing testing
the below. Really, if we have reasons to belie
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/11 02:00, Richard Guenther wrote:
>
>> So the question is do we want to proceed with any of this work?
>> If so I can update the patch, if not I'll go back to my warning
>> work :-)
>
> I think we do want to continue with this work - probabl
Hello,
LTO crashes during debug info generation while seamlessly trying to
see if an anonymous union type has template info, using the
TYPE_TEMPLATE_INFO accessor. That type's TYPE_NAME is NULL and we
TYPE_TEMPLATE_INFO shouldn't crash on that.
The first hunk (the change to TYPE_ALIAS_P) is what
I've been working on improving the running of the testsuite in C++11
mode; one of the failures it found was an odd error on
g++.dg/inherit/using5.C due to the compiler trying to parse 'using B::f'
as an alias-declaration. Fixed by bailing out early if parsing fails.
Tested x86_64-pc-linux-gnu
I'm improving the C++11 coverage of the testsuite, which resulted in
several failures on non-type argument tests in the current testsuite.
Fixed by folding constant expressions in fewer cases.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b1ec006abd6e4dbf45fca99160b09dab0827a10c
Author:
OK.
Jason
On Mon, 7 Nov 2011, Tristan Gingold wrote:
> Hi,
>
> DEC-C for vms has '#pragma __extern_prefix' which is not unlike '#pragma
> extern_prefix' supported by DEC-C for Tru64.
>
> This patch adds supports for the VMS version (which can save and restore
> the current prefix). It reuses most of th
While working on an earlier PR I noticed that make check-c++0x wasn't
actually running a lot of tests in C++11 mode because the -std=c++11
that it added came before the default arguments, so any test without a {
dg-options } line would still be run in C++98 mode. So I've reworked
the C++ tests
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/11 01:09, Paolo Bonzini wrote:
> On 11/08/2011 09:24 PM, Jeff Law wrote:
>> We don't have access to those assertions as they're removed well
>> prior to this pass running. However, if we did, or if we had
>> redundant PHIs in the stream which
On Wed, 9 Nov 2011, Jason Merrill wrote:
> While working on an earlier PR I noticed that make check-c++0x wasn't actually
> running a lot of tests in C++11 mode because the -std=c++11 that it added came
> before the default arguments, so any test without a { dg-options } line would
> still be run
On Wed, Nov 09, 2011 at 10:53:34AM -0700, Jeff Law wrote:
> > which is only different on undefined paths. But I'm not sure that
> > more complicated cases, where there are other instructions between
> > the "if" and "*p = 0", would also be allowed by the C standard.
> > For example, I think a func
On 11/09/2011 01:02 PM, Joseph S. Myers wrote:
To confirm: what do the PASS or FAIL lines look like?
For tests run in both modes, they look like
PASS: g++.dg/whatever -std=c++98
PASS: g++.dg/whatever -std=c++11
Jason
Tested on x86_64-linux. This *ought* to fix RO's Solaris problem.
Committed.
r~
commit 67ba1f57ef6bafdcc0d5e43dbe5793367622977b
Author: rth
Date: Wed Nov 9 18:09:53 2011 +
libitm: Configure for gas cfi pseudo ops.
* asmcfi.m4: New file.
* configure.ac (GCC_
As discussed in:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg00927.html
This puts "flag_next_runtime" into the global options structure
-- hopefully this will pave the way for extracting the information
from objects when doing LTO and making sure that it is (a) consistent
- and (b) that
With this test, build_base_path was crashing because it (reasonably)
assumed that if we're in a constructor with virtual bases, we can look
at current_in_charge_parm. But we can't in a template, even when we've
cleared processing_template_decl for the sake of
fold_non_dependent_expr. So don't
Richard Henderson writes:
> Tested on x86_64-linux. This *ought* to fix RO's Solaris problem.
Right, that's equivalent to, though cleaner than, what I've done.
There are a few outstanding issues on Solaris/x86 with Sun as:
* as doesn't grok the GNU-stack note in config/x86/sjlj.S (likewise os
Hi,
I committed the trivial patch below as obvious to trunk:
2011-11-09 Janne Blomqvist
* intrinsics/time_1.h (gf_gettime): Simplify time() usage.
Index: libgfortran/intrinsics/time_1.h
===
--- libgfortran/intrinsics/ti
On 11/09/2011 10:23 AM, Rainer Orth wrote:
> * as doesn't grok the GNU-stack note in config/x86/sjlj.S (likewise osf
> as in config/alpha/sjlj.S):
>
> +#if defined __ELF__ && defined __linux__
> .section .note.GNU-stack, "", @progbits
> +#endif
I'll include that in another __ELF__ patch I'm pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/07/11 15:36, Richard Guenther wrote:
>
> Yes. tree-affine does this for a sum of expressions of the form a
> + b * c. It collects such sum, optimizes it (and you can
> add/subtract or scale these things) and re-emit the new simplified
> form.
On Thu, Nov 3, 2011 at 11:05 AM, Roland McGrath wrote:
> On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie wrote:
>> The patch looks OK to me.
>
> Thanks! As I'm still not a GCC committer, someone please check it in for me.
> If people would like me to handle the merge over to src/ myself, I'd be
> gl
> I'll hang on .. and test stuff ;-)
Try now. I've committed the following.
r~
commit f29a2041f32773464e226a83f41762c2e9cf658e
Author: rth
Date: Wed Nov 9 18:38:21 2011 +
libitm: de-ELF-ize x86/sjlj.S.
* config/x86/sjlj.S: Protect elf directives with __ELF__.
On 9 Nov 2011, at 18:39, Richard Henderson wrote:
I'll hang on .. and test stuff ;-)
Try now. I've committed the following.
sjlj.S now builds ...
... similar issues are showing in x86_sse.S (I will try and look at
those, if you have not already started).
Iain
On Wed, Nov 09, 2011 at 10:33:12AM -0800, Richard Henderson wrote:
> > If the code ensures at runtime that AVX insns (or SSE for that matter)
> > are only used if hardware and OS are capable of executing them, one
> > can deal with this with the equivalent of
> > gcc/testsuite/gcc.target/i3
From: Eric Botcazou
Date: Wed, 9 Nov 2011 17:41:36 +0100
> There isn't an equivalent for 32-bit, is it? That is, you can load 8, 16 and
> 64 bits in the upper FP regs, but not 32 bits?
Indeed, you need to use normal 32-bit loads and thus the lower 32
float regs.
BTW, I suspect the paradoxical
On 11/09/2011 10:50 AM, Jakub Jelinek wrote:
> Aren't the symbol versions part of the ABI discussed with Intel and others
> though?
Ug. Probably. Though they never actually responded wrt the symbol versions
when we talked; none of the guys on the conference call undersood that bit
about how ELF
> Ping. Anybody going to do this commit for me? (If insteaed someone would
> like to add me to the gcc group so I can do "write after approval", that
> would be fine too.)
Done.
On Wed, 2011-11-09 at 19:50 +0100, Jakub Jelinek wrote:
> On Wed, Nov 09, 2011 at 10:33:12AM -0800, Richard Henderson wrote:
> > > If the code ensures at runtime that AVX insns (or SSE for that matter)
> > > are only used if hardware and OS are capable of executing them, one
> > > can deal wi
On 11/09/2011 10:58 AM, Torvald Riegel wrote:
> This ABI is explicitly for x86 on Linux (we've ignored the Windows
> version of it so far). We thus can define it differently (or just offer
> a subset of the symbols) on other architectures/platforms.
Subsets are dangerous. For any platform that ha
On Wed, Nov 09, 2011 at 10:55:53AM -0800, Richard Henderson wrote:
> On 11/09/2011 10:50 AM, Jakub Jelinek wrote:
> > Aren't the symbol versions part of the ABI discussed with Intel and others
> > though?
>
> Ug. Probably. Though they never actually responded wrt the symbol versions
> when we ta
On Wed, Nov 2, 2011 at 09:33, Tobias Burnus wrote:
> Dear all,
>
> attached is an updated version of Patch 2. The change is that I removed the
> global variable for fill_st_vector and updated the comment for
> do_traverse_symtree to make assumptions clearer.
>
> This version of the patch was build
On 11/09/2011 11:03 AM, Jakub Jelinek wrote:
> On Wed, Nov 09, 2011 at 10:55:53AM -0800, Richard Henderson wrote:
>> On 11/09/2011 10:50 AM, Jakub Jelinek wrote:
>>> Aren't the symbol versions part of the ABI discussed with Intel and others
>>> though?
>>
>> Ug. Probably. Though they never actual
NAND patchup arithmetic was missing the 2 stage AND then NOT operation.
Instead it was falling into the same sequence as every other operation and
trying to perform a binary operation on a NOT.
I managed to modify and existing testcase to trigger the bug without requiring
a configuration with RTL
On 11/07/2011 01:14 PM, Jakub Jelinek wrote:
> * function.h (requires_stack_frame_p): New prototype.
> * function.c (requires_stack_frame_p): No longer static.
> * config/i386/i386.c (ix86_finalize_stack_realign_flags): If
> stack_realign_fp was just a conservative guess for
On 02 Nov 2011 21:52, Janne Blomqvist wrote:
On Wed, Nov 2, 2011 at 22:25, Tobias Burnus wrote:
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 libq
On Wed, 9 Nov 2011, Iain Sandoe wrote:
> I am probably missing something
> - but there doesn't seem to be a ready way to set the Init() value of a flag
> depending on the target
The way that is done is to use an expression inside Init() that uses a
target macro (it needs to be a macro, not a hoo
I said elsewhere that I would convert this to __atomic, but then
I re-read my commentary about using cmpxchg *without* a lock prefix.
What we're looking for here is more or less non-interruptible,
rather than atomic. And apparently I benchmarked this a while back
as a 10x performance improvement.
On Mon, 7 Nov 2011, Tristan Gingold wrote:
> With this patch, these two directories are search in the include path
> and added if found. This is mostly a VMS specific patch, except I
> needed to add a function to get include pathes.
>
> Tested by cross compiling for alpha-vms and ia64-vms.
>
Ian Lance Taylor writes:
> libgcc/ChangeLog:
>
> 2011-11-07 Ian Lance Taylor
>
> * generic-morestack.c: Include .
> (uintptr_type): Define.
> (struct initial_sp): Add dont_block_signals field. Reduce size of
> extra array by 1.
> (allocate_segment): Set prev fiel
On Wed, Nov 09, 2011 at 09:32:28AM -0500, Patrick Marlier wrote:
>
> * gcc.dg/tm/memopt-1.c: Adjust regexp.
This results in
ERROR: (DejaGnu) proc "248" does not exist.
- [] is tcl procedure invocation.
Testing following, will commit soon if it succeeds:
2011-11-09 Jakub Jelinek
On 11/09/2011 03:23 PM, Jakub Jelinek wrote:
On Wed, Nov 09, 2011 at 09:32:28AM -0500, Patrick Marlier wrote:
* gcc.dg/tm/memopt-1.c: Adjust regexp.
This results in
ERROR: (DejaGnu) proc "248" does not exist.
- [] is tcl procedure invocation.
Testing following, will commit soon if
Hi,
2011/11/9 Jason Merrill :
> On 11/09/2011 01:02 PM, Joseph S. Myers wrote:
>>
>> To confirm: what do the PASS or FAIL lines look like?
>
> For tests run in both modes, they look like
>
> PASS: g++.dg/whatever -std=c++98
> PASS: g++.dg/whatever -std=c++11
Nice, but ... is there a way to launch
2011/11/9 Jeff Law :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/07/11 15:36, Richard Guenther wrote:
>
>>
>> Yes. tree-affine does this for a sum of expressions of the form a
>> + b * c. It collects such sum, optimizes it (and you can
>> add/subtract or scale these things) and re-
On 9 November 2011 10:19, Paolo Carlini wrote:
> Hi
>>
>> I checked, and it's currently broken :)
>>
>> We do the wrong thing for allocators with
>> propagate_on_container_swap==true.
>>
>> I think the fix might be as simple as constructing the new container
>> with a copy of the old one's allocato
> Thanks for looking into the 64-bit failures, and actually if you want
> I can work on fixing them myself this afternoon.
Yes, you probably have a better grasp on the code than me.
--
Eric Botcazou
Hi!
When a bool store gets a pattern stmt, we need to update
DR_STMT (otherwise the original rather than replaced stmts
are used e.g. for interleaving etc.).
Bootstrapped/regtested on x86_64-linux and i686-linux, testcase
tested on powerpc64-linux, ok for trunk?
2011-11-09 Jakub Jelinek
Hi!
We don't have a V4SImode vec_interleave_{low,high}v4si patterns
for TARGET_SSE, the following patch works around that by using
what TARGET_SSE has (vec_interleave_{low,high}v4sf) instead of
ICEing.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-11-09 Jakub Jelinek
On 11/09/2011 01:34 PM, Jakub Jelinek wrote:
> PR target/50911
> * config/i386/i386.c (expand_vec_perm_interleave2): If d->vmode is
> V4SImode, !TARGET_SSE2 and punpck[lh]* is needed, change dremap.vmode
> to V4SFmode.
>
> * gcc.dg/torture/vshuf-16.inc: Add interleave
Hello.
This patch removes obsolete FUNCTION_VALUE_REGNO_P macro from CRIS back end
in the GCC and introduces equivalent TARGET_FUNCTION_VALUE_REGNO_P target
hook.
Regression tested on cris-axis-elf.
OK to install?
* config/cris/cris.c (cris_function_value_regno_p): Make static.
On 11/09/2011 04:01 PM, Fabien Chêne wrote:
Nice, but ... is there a way to launch the testsuite with only one
mode at a time ?
Not currently.
Jason
On Nov 9, 2011, at 10:12 AM, Iain Sandoe wrote:
> This puts "flag_next_runtime" into the global options structure
> I needed to deal with '-fobjc-sjlj-exceptions' and elected to remove it -
> - this is because there is only one valid exception model for each
> permutation of runtime and ABI - t
Steve Kargl wrote:
With top of tree, I'm seeing
% ../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran \
--disable-libmudflap --disable-bootstrap
% gmake
I think the issue is that by default the trunk is build (stage 1) by the
system C compiler and the next stages (Stage 2 and
On 11/09/2011 06:53 PM, Jeff Law wrote:
My patch totally ignores the other code on the unexecutable path. So
we can miss externally visible side effects, if we were to somehow get
on the unexecutable path. But that's the whole point, in a conforming
program we can't ever get on the unexecutable
Missing a call to check_for_bare_parameter_packs.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3d2892d25a37984099611c02614fc9788e14d4c4
Author: Jason Merrill
Date: Wed Nov 9 14:25:21 2011 -0500
PR c++/51046
* parser.c (cp_parser_range_for): check_for_bare_parameter_packs.
On Wed, Nov 09, 2011 at 11:10:05PM +0100, Tobias Burnus wrote:
> Steve Kargl wrote:
> >With top of tree, I'm seeing
> >
> >% ../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran \
> >--disable-libmudflap --disable-bootstrap
> >% gmake
>
> I think the issue is that by default the tru
In this testcase we weren't watching the return value of
push_tinst_level, so we crashed trying to pop the level we didn't push.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b7eabaa932f7f309630fc7163e64d61b1aba17c8
Author: Jason Merrill
Date: Wed Nov 9 16:39:25 2011 -0500
PR c+
Hi,
I'm trying to make progress on this issue which I find rather
embarrassing in terms of simple uses of constexpr functions and
static_assert. We reject, at instantiation time:
template
struct z
{
static constexpr bool test_constexpr()
{
return true;
}
static void test()
{
static_assert(te
Hi there,
please find attached the patch and the Changelog entry for our work on
the fortran bug #48426.
The attached patch implements the options
-finteger-4-integer-8
-freal-4-real-8
-freal-4-real-10
-freal-4-real-16
-freal-8-real-4
-freal-8-real-10
-freal-8-real-16
to implement a variety of
On Wed, 9 Nov 2011, Tobias Burnus wrote:
> Steve Kargl wrote:
> > With top of tree, I'm seeing
> >
> > % ../gcc4x/configure --prefix=$HOME/work --enable-languages=c,fortran \
> > --disable-libmudflap --disable-bootstrap
> > % gmake
>
> I think the issue is that by default the trunk is build (sta
Not pretty at all. But given the corresponding irritation in writing assembler
wrapper functions, it seems like it's about a wash.
Tested with and without HAVE_AS_AVX on x86_64-linux.
r~
commit 856dd9f4777fbafce3038e889e9a9bf4815d
Author: Richard Henderson
Date: Wed Nov 9 16:28:45 2011 -
On 11/09/2011 05:45 PM, Paolo Carlini wrote:
finish_id_expression is called from cp_parser_primary_expression with a
true allow_non_integral_constant_expression_p and the error doesn't
occur.
Yes, allow_non_integral_constant_expression_p should always be true in
C++11.
Jason
On 11/10/2011 01:43 AM, Jason Merrill wrote:
On 11/09/2011 05:45 PM, Paolo Carlini wrote:
finish_id_expression is called from cp_parser_primary_expression with a
true allow_non_integral_constant_expression_p and the error doesn't
occur.
Yes, allow_non_integral_constant_expression_p should alwa
On 11/09/2011 07:56 PM, Paolo Carlini wrote:
-
/*allow_non_integral_constant_expression_p=*/false,
+
/*allow_non_integral_constant_expression_p=*/true,
This should be (cxx_dialect >= cxx0x) rather than true.
Jason
1 - 100 of 106 matches
Mail list logo
