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
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 having, for the time
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 rguent...@suse.de
* gimple-fold.c
On Tue, Nov 8, 2011 at 6:10 PM, Xinliang David Li davi...@google.com 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,
2011/11/8 Tobias Burnus bur...@net-b.de:
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
On Tue, Nov 8, 2011 at 8:35 PM, Jeff Law l...@redhat.com 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 ja...@redhat.com
wrote:
Hi!
This patch attempts to optimize VEC_BASE if we know that
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
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
* 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
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
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
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 patch
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 paolo.carl...@oracle.com
PR c++/51047
*
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
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 it doesn't
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).
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 code,
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
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
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 overlaps
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
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.
I
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 than
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
-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 - probably not
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
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
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
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 the
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++
-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 were
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 in
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 function call
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
Richard Henderson r...@redhat.com 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
Hi,
I committed the trivial patch below as obvious to trunk:
2011-11-09 Janne Blomqvist j...@gcc.gnu.org
* intrinsics/time_1.h (gf_gettime): Simplify time() usage.
Index: libgfortran/intrinsics/time_1.h
===
---
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 preparing
-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.
Kai,
On Thu, Nov 3, 2011 at 11:05 AM, Roland McGrath mcgra...@google.com wrote:
On Thu, Nov 3, 2011 at 10:55 AM, DJ Delorie d...@redhat.com 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
I'll hang on .. and test stuff ;-)
Try now. I've committed the following.
r~
commit f29a2041f32773464e226a83f41762c2e9cf658e
Author: rth rth@138bc75d-0d04-0410-961f-82ee72b054a4
Date: Wed Nov 9 18:38:21 2011 +
libitm: de-ELF-ize x86/sjlj.S.
* config/x86/sjlj.S:
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
From: Eric Botcazou ebotca...@adacore.com
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
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 with this
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 has
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 talked;
On Wed, Nov 2, 2011 at 09:33, Tobias Burnus bur...@net-b.de 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
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 actually responded
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
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 a
On 02 Nov 2011 21:52, Janne Blomqvist wrote:
On Wed, Nov 2, 2011 at 22:25, Tobias Burnusbur...@net-b.de 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
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 hook,
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
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.
Ok
Ian Lance Taylor i...@google.com writes:
libgcc/ChangeLog:
2011-11-07 Ian Lance Taylor i...@google.com
* generic-morestack.c: Include string.h.
(uintptr_type): Define.
(struct initial_sp): Add dont_block_signals field. Reduce size of
extra array by 1.
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 ja...@redhat.com:
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
2011/11/9 Jeff Law l...@redhat.com:
-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
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 allocator, so even if it
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
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 low
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
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 - thus
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
Missing a call to check_for_bare_parameter_packs.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 3d2892d25a37984099611c02614fc9788e14d4c4
Author: Jason Merrill ja...@redhat.com
Date: Wed Nov 9 14:25:21 2011 -0500
PR c++/51046
* parser.c (cp_parser_range_for):
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 trunk is build
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 ja...@redhat.com
Date: Wed Nov 9 16:39:25 2011
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:
templateclass T
struct z
{
static constexpr bool test_constexpr()
{
return true;
}
static void test()
{
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 (stage 1) by the
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 r...@redhat.com
Date: Wed Nov 9
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
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
On 11/09/2011 03:58 PM, Fabien Chêne wrote:
Well, here it is. I've added a very simple function in order to guess
if a name is a declaration or a definition.
This seems unnecessary; a definition is also a declaration, so it's
always correct to talk about a previous declaration.
+
OK. And yes, we ought to fix that cannot convert error since often
that's not the problem.
Jason
Trunk gcc mis-handles following volatile bitfield case on ARM target:
$ cat a.c
extern void check(int);
typedef struct {
volatile unsigned short a:8, b:8;
} BitStruct;
BitStruct bits = {1, 2};
int main ()
{
check(bits.a);
return 0;
}
$ arm-none-eabi-gcc -v 21 |grep gcc version
gcc version
On 9 November 2011 23:32, Jakub Jelinek ja...@redhat.com wrote:
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
Hello guys,
So, what about the patch? I think since we already have zee patch it
would be great to use it as more general optimization. I tested it on
EEMBC 2.0 on Atom and it showed 1% performance gain in geomean on 32
bit which is really good for such simple optimization. For OOO archs
patch is
93 matches
Mail list logo
