This patch replaces the existing x1dynarray* tests with new versions.
These versions test more in finer grades.
x1dynarray1.cc : basic template data structure of PODs
x1dynarray2a.cc + wrapped in namespace; accessed with using directive
x1dynarray2b.cc | wrapped in namespace; accessed with qualif
On 07/01/11 16:39:55, Mike Stump wrote:
> You can use that to allocate additional data for the frontend's exclusive
> use.
> See the C++ frontend, it uses language specific data. :-)
Heh. It sounds like this language-specific hook works well for language
front-ends that aren't sharing the logi
On 07/02/11 00:06:07, Jakub Jelinek wrote:
> Yes, look at DECL_VALUE_EXPR/SET_DECL_VALUE_EXPR/DECL_HAS_VALUE_EXPR_P
> or DECL_DEBUG_EXPR/SET_DECL_DEBUG_EXPR/DEBUG_EXPR_IS_FROM.
OK, thanks. The UPC front end will be changed use a similar method to
encode UPC's block size.
On 07/01/11 19:28:34, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Gary Funck wrote:
> GF: * Most of the #ifdef conditionals have been removed. Some target macros
> GF: have been defined and documented in tm.texi. We still have some questions
>
> [...]
> I looked at the first of the documented ma
So I did find a better way of doing this, see Issue #4627087.
I'll go ahead and close this issue.
On 2011/07/01 01:27:26, Gabriel Charette wrote:
notice_global_symbol is actually called in the parser (before we
stream out).
I just confirmed this by setting a break point on the function in th
As variables are discovered (while parsing the header) they are added to the
varpool and their RTL is built.
We do not stream, nor the varpool, nor the RTL (and I don't think we want to +
that wouldn't work with multiple pph).
We want to rebuild the varpool when streaming the global variables o
I should add that this exposed two assembly comparison failures which
slipped in a previous check-in when this problem was still up.
Namely:
FAIL: g++.dg/pph/x1dynarray0.cc (assembly comparison)
FAIL: g++.dg/pph/x1dynarray1.cc (assembly comparison)
Lawrence is reorganizing those tests as we spe
On 7/1/11, Gabriel Charette wrote:
> One problem now though: `// pph asm xdiff`, only flags for asm diffs,
> but those could be different diffs after a change (for the better or
> worse) and this won't be caught. It's probably hard to get something
> precise on this, but maybe we could simply add
LGTM
On 7/1/11, Gabriel Charette wrote:
> [string compare "dg-do-what" "run"] which was used before would always
> return true.
>
> Thus the tests would no longer even get to the asm diff section...
>
> Me and Lawrence tried to find a way to get the content of the "dg-do-what"
> variable, but cou
[string compare "dg-do-what" "run"] which was used before would always return
true.
Thus the tests would no longer even get to the asm diff section...
Me and Lawrence tried to find a way to get the content of the "dg-do-what"
variable, but couldn't.
We decided to revert to this quick hack fix
On Jul 1, 2011, at 2:34 PM, Gary Funck wrote:
> Is there some way to use the language specific information hook?
>
>struct GTY(()) tree_type_with_lang_specific {
> struct tree_type_common common;
> /* Points to a structure whose details depend on the language in use. */
> struc
On 07/02/11 00:11, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Bernd Schmidt wrote:
>
>>> * The global tree nodes for various modes are suspicious. Why are they
>>> needed at all?
>>
>> Do you mean only the PImode ones or also intQI_type_node etc.? These are
>> used to pick a suitable type in c
Hey,
so I really like the new clean testing system, so that we always
quickly see what we fixed/broked with a local change.
One problem now though: `// pph asm xdiff`, only flags for asm diffs,
but those could be different diffs after a change (for the better or
worse) and this won't be caught. I
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> On 07/01/11 23:18, Bernd Schmidt wrote:
> >> What is the function of having both PARTIAL_INT_MODE and
> >> FRACTIONAL_INT_MODE?
> >
> > Not having to change all the targets using PARTIAL_INT_MODE immediately
> > to use the better mechanism.
>
> Also, c
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> > * The global tree nodes for various modes are suspicious. Why are they
> > needed at all?
>
> Do you mean only the PImode ones or also intQI_type_node etc.? These are
> used to pick a suitable type in c_common_type_for_size.
All of them.
> > * The
On Fri, Jul 01, 2011 at 02:34:41PM -0700, Gary Funck wrote:
> Is there precedent for this technique being used in other GCC front-ends?
Yes, look at DECL_VALUE_EXPR/SET_DECL_VALUE_EXPR/DECL_HAS_VALUE_EXPR_P
or DECL_DEBUG_EXPR/SET_DECL_DEBUG_EXPR/DEBUG_EXPR_IS_FROM.
Jakub
Not clear why this never showed up on the 4.6 branch, but this now prevents a
parallel LTO bootstrap with Ada enabled from completing on the mainline.
Parallel LTO-bootstrapped, applied on the mainline and 4.6 branch.
2011-07-01 Eric Botcazou
* gcc-interface/Make-lang.in (gnat1): Pr
On 07/01/11 23:18, Bernd Schmidt wrote:
>> What is the function of having both PARTIAL_INT_MODE and
>> FRACTIONAL_INT_MODE?
>
> Not having to change all the targets using PARTIAL_INT_MODE immediately
> to use the better mechanism.
Also, come to think of it, preventing the rest of the compiler fr
On 07/01/11 22:42:55, Jakub Jelinek wrote:
> On Fri, Jul 01, 2011 at 11:31:45AM -0700, Gary Funck wrote:
> > @@ -2405,6 +2469,9 @@ struct GTY(()) tree_type_common {
> >alias_set_type alias_set;
> >tree pointer_to;
> >tree reference_to;
> > + /* UPC: for block-distributed arrays */
> >
Hi!
For debug stmt uses, we don't want any PHI nodes to be created
just because of them, so the debug uses need to be ignored
during decisions which PHI nodes to add.
Unfortunately that means get_current_def can't be always trusted.
The following patch trusts it in a few cases where I'm reasonably
On 07/01/11 22:36, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Bernd Schmidt wrote:
>> The idea here is that there is more than one target that supports 40 bit
>> operations, so why shouldn't we have support for it in
>> target-independent code and libgcc? It differs from QI/HI/SImode etc. in
>> t
Hi!
__builtin_assume_aligned is a pass thru call, preserves
object size.
Bootstrapped/regtested on x86_64-linux and i686-linux, committed
as obvious.
2011-07-01 Jakub Jelinek
* tree-object-size.c (pass_through_call): Handle
BUILT_IN_ASSUME_ALIGNED.
--- gcc/tree-object-size.c
One more general point:
There are further issues around what we might call "extended types that
behave much like integer and floating-point types", especially for C++;
see my comment in PR 43622, and the references therein. How to fix these
(again, while avoiding hardcoding references to such
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> On 07/01/11 21:49, Joseph S. Myers wrote:
> > On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> >
> >> * Should we add an __int40_t keyword, or just do a pushdecl for it?
> >>The patch currently does the latter to match __int128_t, but
> >>decimal floa
On Fri, Jul 01, 2011 at 11:31:45AM -0700, Gary Funck wrote:
> @@ -2405,6 +2469,9 @@ struct GTY(()) tree_type_common {
>alias_set_type alias_set;
>tree pointer_to;
>tree reference_to;
> + /* UPC: for block-distributed arrays */
> + tree block_factor;
>
I think this is undesirable. U
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> On 07/01/11 22:04, Joseph S. Myers wrote:
> > I should add: make the type, the new mode, the testcases etc. entirely
> > target-specific; target-independent GCC should not need to know or care
> > about the specifics of this type. It's bad enough targe
On 07/01/11 19:28:34, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Gary Funck wrote:
> GF: * Most of the #ifdef conditionals have been removed. Some target macros
> GF: have been defined and documented in tm.texi. We still have some questions
>
> For each target macro, what is the justification
On 07/01/2011 01:23 PM, Torvald Riegel wrote:
> Add vector-like container, use it for gtm_transaction::undo_log.
>
> * containers.h: New file.
> * util.cc (xmalloc, xrealloc): Accept cacheline-alloc flag.
> * libitm_i.h (xmalloc, xrealloc): Moved declarations from here ..
Replacing assert with error.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e42789795f05e88b0b55c5da0670aa827ad046b2
Author: Jason Merrill
Date: Fri Jul 1 14:06:46 2011 -0400
PR c++/48261
* pt.c (lookup_template_function): Handle non-function.
diff --git a/gcc/cp/pt.c b/gcc/
Attached patch adds a vector-like container implementation and uses it
for a transaction's undo log. Also, adds a flag to xmalloc/xrealloc that
requests the allocated data to be on cache lines that are not shared
with data accessed by other threads (this will get an actual
implementation in a later
We weren't preserving the parenthesis in the template context. Oops.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9108c3486dd1a408fdd7c64a0393aa5eec1e7a14
Author: Jason Merrill
Date: Fri Jul 1 13:43:22 2011 -0400
PR c++/48593
* pt.c (tsubst_qualified_id): Check PTRMEM_OK_P
On 07/01/11 22:18, Paul Koning wrote:
>> PDImode is so far always defined as MODE_PARTIAL_INT which is handled
>> quite differently (i.e. by not handling it very much at all). IMO it
>> would be a bad idea to overload the name.
>
> Would it make sense to fix the "not much at all" problem?
Ideally
Since DR 115, people have been able to designate a single function
specialization with a template-id. When it's then used in a call it
gets marked used, but uses in other situations weren't getting marked,
leading to undefined symbol errors.
Tested x86_64-pc-linux-gnu, applying to trunk.
comm
On 07/01/11 21:49, Joseph S. Myers wrote:
> On Fri, 1 Jul 2011, Bernd Schmidt wrote:
>
>> * Should we add an __int40_t keyword, or just do a pushdecl for it?
>>The patch currently does the latter to match __int128_t, but
>>decimal float and fixed-point support uses keywords. This may make
On Jul 1, 2011, at 4:14 PM, Bernd Schmidt wrote:
> On 07/01/11 22:04, Joseph S. Myers wrote:
>> I should add: make the type, the new mode, the testcases etc. entirely
>> target-specific; target-independent GCC should not need to know or care
>> about the specifics of this type. It's bad enough
On 07/01/11 22:04, Joseph S. Myers wrote:
> I should add: make the type, the new mode, the testcases etc. entirely
> target-specific; target-independent GCC should not need to know or care
> about the specifics of this type. It's bad enough target-independent GCC
> knowing about HImode, SImode,
This patch is OK, I think I have a slight preference for the warning
where it is.
Jason
This is indeed a problem. Good catch; thanks!
-DeLesley
On Fri, Jul 1, 2011 at 11:50 AM, Martin Jambor wrote:
> Hi,
>
> On Fri, Jul 01, 2011 at 09:31:30AM -0700, Delesley Hutchins wrote:
>> > Just out of curiosity, I does your
>> > analysis crash also on the testcase below (add the Mutex fiel
I should add: make the type, the new mode, the testcases etc. entirely
target-specific; target-independent GCC should not need to know or care
about the specifics of this type. It's bad enough target-independent GCC
knowing about HImode, SImode, DImode and TImode outside default target
hook im
On 07/01/2011 02:02 AM, Richard Earnshaw wrote:
> On 24/06/11 14:18, Ramana Radhakrishnan wrote:
>> On 24/06/11 01:40, Janis Johnson wrote:
>>> Test gcc.target/arm/pr42093.c, added by Ramana, requires support for
>>> arm_thumb2 but fails for those targets. The patch for which it was
>>> added modi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49605
There's a spurious warning because I didn't realise that build_delete
is used for destroying automatic variables as well as for delete
expression, this fixes it by checking for sfk_deleting_destructor, is
that the right thing to do?
Tested x86_64-
On Fri, 1 Jul 2011, Bernd Schmidt wrote:
> * Should we add an __int40_t keyword, or just do a pushdecl for it?
>The patch currently does the latter to match __int128_t, but
>decimal float and fixed-point support uses keywords. This may make
>a difference for (existing) code using "uns
On Fri, 1 Jul 2011, Dr. David Alan Gilbert wrote:
> +/* For write */
> +#include
> +/* For abort */
> +#include
Please don't include system headers in libgcc without appropriate
inhibit_libc checks for bootstrap purposes. In this case, it would seem
better just to declare the functions you n
On Fri, 1 Jul 2011, Gary Funck wrote:
> * Most of the #ifdef conditionals have been removed. Some target macros
> have been defined and documented in tm.texi. We still have some questions
For each target macro, what is the justification requiring it to be a
macro rather than a hook documented
Hi,
On Fri, Jul 01, 2011 at 09:31:30AM -0700, Delesley Hutchins wrote:
> > Just out of curiosity, I does your
> > analysis crash also on the testcase below (add the Mutex field if it
> > is necessary)?
>
> No, the static type of b (in b->test()) remains Bar* in gimple, so the
> analysis works fin
Am 01.07.2011 14:34, schrieb Janne Blomqvist:
On Thu, Jun 30, 2011 at 21:09, Thomas Koenig wrote:
Good point. I have done so in the attached patch
Seems you forgot to attach it.. ;)
Oops, I hadn't realized your crystal ball was broken :-)
Is this better?
Thomas
2011-06-30 Thom
On 01/07/11 16:54, Paolo Bonzini wrote:
> On 07/01/2011 04:55 PM, Stubbs, Andrew wrote:
>>> >
>>> > What about (u128)c + (u64)((s8)a * (s8)b)? You cannot convert this to
>>> > (u128)c + (u128)((s8)a * (s8)b).
>> Oh I see, sorry. Yes, that's exactly what I'm trying to do here.
>>
>> No, wait, I don'
On 06/14/2011 01:38 PM, Jason Merrill wrote:
While I was at it, I've also tweaked the compiler to also print the
typedef-stripped version of a type when appropriate, which should help
with understanding template error messages.
I noticed that this was sometimes printing an aka that was exactly
> Looks OK to me.
Thanks, DJ. I've just checked the patch in on the GCC side.
I will push it on the src/GDB CVS momentarily.
--
Joel
get_mode_bounds should also use GET_MODE_PRECISION, but this exposes a
problem on ia64 - BImode needs to be handled specially here to work
around another preexisting special case in gen_int_mode.
Bernd
* stor-layout.c (get_mode_bounds): Use GET_MODE_PRECISION. Special
case BImode
This fixes a few random problems that occur when you add a new
fractional integer mode - for example, trying to expand doubleword
shifts normally for them, or trying to generate 40->64 bit widening
multiply. In some cases where it seems we can only deal with modes where
precision == bitsisze, I've
A bug fix discovered while working on the other patches. Previously,
this was a comparison of a GET_MODE_BITSIZE vs a GET_MODE_SIZE value.
After the other patches, it's GET_MODE_PRECISION vs GET_MODE_SIZE, which
is just as wrong, so change it.
Bernd
* rtlanal.c (nonzero_bits1): Don't com
This replaces remaining uses of GET_MODE_BITSIZE with GET_MODE_PRECISION
where doing so seems relatively obviously correct. The patch is intended
to cover the expander.
Bernd
* optabs.c (expand_binop): Use GET_MODE_PRECISION instead of
GET_MODE_BITSIZE where appropriate.
A lot of code tests GET_MODE_BITSIZE (mode) <= HOST_BITS_PER_WIDE_INT to
determine whether it can operate on values in the mode using
HOST_WIDE_INT. This patch hides that behind a new macro, which now uses
GET_MODE_PRECISION.
Bernd
* machmode.h (HWI_COMPUTABLE_MODE_P): New macro.
Adds a new helper function, paradoxical_subreg_p, and uses that instead
of explicit mode comparisons. The function now uses GET_MODE_PRECISION
instead of GET_MODE_BITSIZE. Additional, some code in reload testing
subreg modes is adjusted to do the same.
Bernd
* emit-rtl.c (paradoxical_sub
Most users of TRULY_NOOP_TRUNCATION have machine modes they want to
examine, so hide these behind a new macro TRULY_NOOP_TRUNCATION_MODES_P.
This now uses GET_MODE_PRECISION instead of GET_MODE_BITSIZE.
Bernd
* machmode.h (TRULY_NOOP_TRUNCATION_MODES_P): New macro.
* combine.c (m
A long time ago, this piece of code ended in a call to GEN_INT. Now that
we're using gen_int_mode, we needn't do the sign extension ourselves.
Bernd
* simplify-rtx.c (simplify_ternary_operation): Remove dead code.
Index: baseline-trunk/gcc/simplify-rtx.c
We have a function mode_signbit_p, which tests whether a given rtx is
equal to the sign bit of a given mode. This patch adds some similar
helper functions and uses them to simplify tests. Also, in some
instances of zero- and sign-extending, I've changed some bit shifting to
uses of GET_MODE_MASK.
At some point we've grown a shift_truncation_mask hook, but we're not
using it everywhere we're masking shift counts. This patch changes the
instances I found.
Bernd
* simplify-rtx.c (simplify_const_binary_operation): Use the
shift_truncation_mask hook instead of performing modulo
I'm working on a patch to support __int40_t for the C6X target. This
will involve a new integer mode with bitsize 64, and precision 40. A lot
of the existing code doesn't make a distinction between the two values,
since at the moment they are identical for all integer modes (except
BImode).
This p
On Fri, 01 Jul 2011 18:27:36 +0200, Jason Merrill wrote:
> OK.
Checked in:
http://gcc.gnu.org/viewcvs?view=revision&revision=175761
No regressions on gcc-4.6.1-1.fc15.x86_64 (it is not trunk but hopefully
similar enough).
Thanks,
Jan
On 1 July 2011 17:03, Richard Henderson wrote:
> On 07/01/2011 08:55 AM, Dr. David Alan Gilbert wrote:
>> +/* Check that the kernel has a new enough version at load */
>> +void __check_for_sync8_kernelhelper (void)
>> +{
>> + if (__kernel_helper_version < 5)
>> + {
>> + const char err[] =
OK.
Jason
Hi Paolo,
Thank you for the review.
> > Ping for:
> > http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00440.html
> personally, I have only minor comments, like only 2011 as Copyright
> year for new files, and please also regtest on a gnu-linux system.
I've updated the Copyright year and removed the
On 06/28/11 18:14, Andrew Stubbs wrote:
> unsigned long long
> foo (unsigned long long a, unsigned char b, unsigned char c)
> {
> return a + b * c;
> }
>
> This appears to be entirely unsigned maths with plenty of spare
> precision, and therefore a dead cert for any SI->DI
> multiply-
"H.J. Lu" writes:
> On Wed, Jun 29, 2011 at 7:06 AM, H.J. Lu wrote:
>> On Wed, Jun 29, 2011 at 1:45 AM, Richard Sandiford
>> wrote:
>>> "H.J. Lu" writes:
@@ -706,7 +706,13 @@ precompute_register_parameters (int num_actuals,
struct arg_data *args,
pseudo now. TLS symbol
> If you in some way rely on static types of those pointers, you may be
> in for a number of unpleasant surprises, because these types do not
> really have any meaning at all.
Annotalysis is just a static analyzer, so if the types are somehow
inaccurate (as they are in certain cases), then the onl
On 07/01/2011 08:55 AM, Dr. David Alan Gilbert wrote:
> +/* Check that the kernel has a new enough version at load */
> +void __check_for_sync8_kernelhelper (void)
> +{
> + if (__kernel_helper_version < 5)
> +{
> + const char err[] = "A newer kernel is required to run this binary.
> (__k
As per pr/48126 Michael Edwards spotted that in the case where
the compare fails in the cmpxchg, the barrier at the end wasn't taken
theoretically allowing a following load to float up above the load
value compared.
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index 057f9ba..39057d2 1
Provide fallbacks for 64bit atomics that call Linux commpage helpers
when compiling for older machines. The code is based on the existing
linux-atomic.c for other sizes, however it performs an init time
check that the kernel is new enough to provide the helper.
This relies on Nicolas P
Hi,
On Thu, Jun 30, 2011 at 06:36:01PM +0200, Martin Jambor wrote:
> Hi,
>
> On Thu, Jun 30, 2011 at 03:39:55PM +0200, Martin Jambor wrote:
> > Hi,
> >
> > I had to add a test that the analyzed expression is not an SSA name.
> > This has been approved by Rchi on IRC yesterday. Thus, I have
> >
On 07/01/2011 04:55 PM, Stubbs, Andrew wrote:
>
> What about (u128)c + (u64)((s8)a * (s8)b)? You cannot convert this to
> (u128)c + (u128)((s8)a * (s8)b).
Oh I see, sorry. Yes, that's exactly what I'm trying to do here.
No, wait, I don't see. Where are these multiple widening multiplies
you'r
Hi,
This is a series of 3 patches relating to ARM atomic operations.
1) Provide 64 bit atomic operations using the new ldrexd/strexd in ARMv6k
and above.
2) Provide fallbacks so that when compiled for earlier CPUs a Linux kernel
asssist is called (as per 32bit and smaller ops)
3)
So updated patch (bootstrapped and tested for all standard languages
plus Ada and Obj-C++) on x86_64-pc-linux-gnu host.
Index: gcc-head/gcc/tree-ssa-forwprop.c
===
--- gcc-head.orig/gcc/tree-ssa-forwprop.c
+++ gcc-head/gcc/tree-ssa-fo
On 01/07/11 14:30, Stubbs, Andrew wrote:
>> Got it now! Casts from signed to unsigned are not value-preserving, but
>> > they are "bit-preserving": s32->s64 obviously is, and s32->u64 has the
>> > same result bit-by-bit as the s64 result. The fact that s64 has an
>> > implicit ... in front,
On Fri, Jul 1, 2011 at 7:25 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>>> Then move it below the definition of struct _Unwind_Context with a
>>
>> It won't work since I need to define a macro before struct _Unwind_Context.
>
> Then this does seem to be a case for libgcc_tm_file indeed. Ugly
On 01/07/11 15:40, Paolo Bonzini wrote:
> On 07/01/2011 03:30 PM, Stubbs, Andrew wrote:
>>> > However, perhaps there is a catch. We can do the following thought
>>> > experiment. What would happen if you had multiple widening multiplies?
>>> > Like 8-bit signed to 64-bit unsigned and then 64-bit un
On 26.05.2011 17:32, Andrey Belevantsev wrote:
On 25.05.2011 19:31, Bernd Schmidt wrote:
On 05/25/2011 03:29 PM, Andrey Belevantsev wrote:
I think the hook is a better idea than the attribute because nobody will
care to mark all offending insns with an attribute.
I don't know. IIRC when I loo
Hi,
On Thu, Jun 30, 2011 at 10:01:58AM -0700, Delesley Hutchins wrote:
> This bug fixes a failure in annotalysis that is caused when gcc does
> not return the correct static type for the callee of a virtual method.
>
> Bootstrapped and passed GCC regression testsuite on x86_64-unknown-linux-gnu.
On 07/01/2011 03:30 PM, Stubbs, Andrew wrote:
> However, perhaps there is a catch. We can do the following thought
> experiment. What would happen if you had multiple widening multiplies?
> Like 8-bit signed to 64-bit unsigned and then 64-bit unsigned to 128-bit
> unsigned? I believe in this
Ping ... !
2011/6/28 Janus Weil :
> Hi all,
>
> here is a patch for a problem which was originally reported as an
> ICE-on-invalid regression (assigning to a type-bound function).
>
> In the course of fixing it, I noticed that it becomes valid according
> to F08 if the function is pointer-valued
"H.J. Lu" writes:
>> Then move it below the definition of struct _Unwind_Context with a
>
> It won't work since I need to define a macro before struct _Unwind_Context.
Then this does seem to be a case for libgcc_tm_file indeed. Ugly that
the unwinder configuration has to be split between two di
On Sun, Jun 19, 2011 at 11:39 AM, H.J. Lu wrote:
> On Fri, Jun 3, 2011 at 5:51 AM, H.J. Lu wrote:
>> On Fri, Jun 3, 2011 at 5:31 AM, Richard Guenther
>> wrote:
>>> On Fri, Jun 3, 2011 at 6:31 AM, H.J. Lu wrote:
On Wed, May 18, 2011 at 8:57 AM, H.J. Lu wrote:
> On Tue, Apr 26, 2011 at
On Fri, Jul 1, 2011 at 7:02 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
What is your suggestion?
>>>
>>> How about moving the md-unwind-support.h include up to the rest of the
>>> includes? The headers usually only define MD_FALLBACK_FRAME_STATE_FOR
>>> and perhaps MD_FROB_UPDATE_CONTEXT,
"H.J. Lu" writes:
>>> What is your suggestion?
>>
>> How about moving the md-unwind-support.h include up to the rest of the
>> includes? The headers usually only define MD_FALLBACK_FRAME_STATE_FOR
>> and perhaps MD_FROB_UPDATE_CONTEXT, everything else is an internal
>> helper macro, so order sho
2011/7/1 Kai Tietz :
> 2011/7/1 Richard Guenther :
>> On Fri, Jul 1, 2011 at 1:44 PM, Kai Tietz wrote:
>>> Ok, here is reworked patch with adjusted testcase.
>>>
>>> ChangeLog gcc/
>>>
>>> 2011-07-01 Kai Tietz
>>>
>>> * tree-ssa-forwprop.c (truth_valued_ssa): New function.
>>> (de
2011/7/1 Richard Guenther :
> On Fri, Jul 1, 2011 at 1:44 PM, Kai Tietz wrote:
>> Ok, here is reworked patch with adjusted testcase.
>>
>> ChangeLog gcc/
>>
>> 2011-07-01 Kai Tietz
>>
>> * tree-ssa-forwprop.c (truth_valued_ssa): New function.
>> (detect_not_expr_operand): New func
On Fri, Jul 1, 2011 at 6:37 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>> On Fri, Jul 1, 2011 at 2:02 AM, Rainer Orth
>> wrote:
>>> "H.J. Lu" writes:
>>>
Here is the updated patch. It works on simple tests.
I am running full tests. I kept config/i386/value-unwind.h
since li
"H.J. Lu" writes:
> On Fri, Jul 1, 2011 at 2:02 AM, Rainer Orth
> wrote:
>> "H.J. Lu" writes:
>>
>>> Here is the updated patch. It works on simple tests.
>>> I am running full tests. I kept config/i386/value-unwind.h
>>> since libgcc/md-unwind-support.h is included too late
>>> in unwind-dw2
We can't take the offsetof a field until after we've laid out the class.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 92f52fccaaf25b5791c0f8bff930fe75d25bd90b
Author: Jason Merrill
Date: Thu Jun 30 23:05:49 2011 -0400
PR c++/49085
* semantics.c (finish_offsetof): Complain a
On 01/07/11 13:33, Paolo Bonzini wrote:
> Got it now! Casts from signed to unsigned are not value-preserving, but
> they are "bit-preserving": s32->s64 obviously is, and s32->u64 has the
> same result bit-by-bit as the s64 result. The fact that s64 has an
> implicit ... in front, while an u64 h
On Fri, Jul 1, 2011 at 1:44 PM, Kai Tietz wrote:
> Ok, here is reworked patch with adjusted testcase.
>
> ChangeLog gcc/
>
> 2011-07-01 Kai Tietz
>
> * tree-ssa-forwprop.c (truth_valued_ssa): New function.
> (detect_not_expr_operand): New function.
> (simplify_bitwise_binar
On Fri, Jul 1, 2011 at 2:02 AM, Rainer Orth
wrote:
> "H.J. Lu" writes:
>
>> Here is the updated patch. It works on simple tests.
>> I am running full tests. I kept config/i386/value-unwind.h
>> since libgcc/md-unwind-support.h is included too late
>> in unwind-dw2.c and I don't want to move it
On Thu, Jun 30, 2011 at 21:09, Thomas Koenig wrote:
> Good point. I have done so in the attached patch
Seems you forgot to attach it.. ;)
--
Janne Blomqvist
On 07/01/2011 01:58 PM, Stubbs, Andrew wrote:
Given this test case:
unsigned long long
foo (unsigned long long a, signed char *b, signed char *c)
{
return a + *b * *c;
}
Those rules say that it should not be suitable for optimization because
there's an implicit cast from s
On Fri, Jul 1, 2011 at 1:58 PM, Stubbs, Andrew wrote:
> On 28/06/11 17:37, Michael Matz wrote:
>>> What I want (and I'm not totally clear on what this actually means) is
>>> > to be able to optimize all the cases where the end result will be the
>>> > same as the compiler produces now (using mul
On 28/06/11 17:37, Michael Matz wrote:
>> What I want (and I'm not totally clear on what this actually means) is
>> > to be able to optimize all the cases where the end result will be the
>> > same as the compiler produces now (using multiple multiply, shift, and
>> > add operations).
> Okay, th
- Original Message -
From: "Richard Guenther"
To: "Kai Tietz"
Cc: gcc-patches@gcc.gnu.org
Sent: Thursday, June 30, 2011 1:36:13 PM
Subject: Re: [patch tree-optimization]: Do bitwise operator optimizations for X
op !X patterns
On Wed, Jun 29, 2011 at 3:00 PM, Kai Tietz wrote:
> - Or
OK, thanks.
Jason
"Joseph S. Myers" writes:
> On Fri, 1 Jul 2011, Rainer Orth wrote:
>
>> 2011-04-08 Rainer Orth
>>
>> * config.gcc: Obsolete alpha*-dec-osf5.1, mips-sgi-irix6.5.
>> * doc/install.texi (Specific, alpha*-dec-osf5.1): Document it.
>> (Specific, mips-sgi-irix6): Likewise.
>
> contri
1 - 100 of 116 matches
Mail list logo
