This fixes PR49603.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-07-01 Richard Guenther rguent...@suse.de
PR tree-optimization/49603
* tree-vect-stmts.c (vectorizable_load): Remove unnecessary
assert.
*
On Thu, 30 Jun 2011, 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
committed the following as revision
On Thu, Jun 30, 2011 at 05:08:49PM -0400, Jason Merrill wrote:
Author: Jason Merrill ja...@redhat.com
Date: Thu Jun 30 00:03:40 2011 -0400
PR c++/48481
* name-lookup.c (struct arg_lookup): Add fn_set.
(add_function): Check it.
(lookup_arg_dependent_1): Initialize
On Thu, Jun 30, 2011 at 7:06 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
On Thu, Jun 30, 2011 at 12:31:44PM +0200, Richard Guenther wrote:
On Thu, Jun 30, 2011 at 12:34 AM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
On the powerpc, switch statements can be expensive, and
On Thu, Jun 30, 2011 at 8:01 PM, Kai Tietz kti...@redhat.com wrote:
Hello,
this patch fixes a typo in type-sinking for bitwise-binary operation X op CST.
ChangeLog gcc/
2011-06-30 Kai Tietz kti...@redhat.com
* tree-ssa-forwprop.c (simplify_bitwise_binary): Fix typo.
ChangeLog
On Thu, Jun 30, 2011 at 8:05 PM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Jun 29, 2011 at 9:16 AM, Michael Matz m...@suse.de wrote:
Hi,
On Wed, 29 Jun 2011, H.J. Lu wrote:
diff --git a/gcc/function.c b/gcc/function.c
index 81c4d39..131bc09 100644
--- a/gcc/function.c
+++
On Thu, Jun 30, 2011 at 8:42 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
As reporteed by Tobias, when printing array ctors the pretty printer would
never print indexes or ranges, which means that e.g.
{[2 ... 71]=7}
ctor was printed as
{7}
and
{[3]=1, [7]=2}
ctor was printed as
{1, 2}
H.J. Lu hjl.to...@gmail.com 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 to be on
the safe side.
Oh please, don't
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 modified support for thumb1. Should the test instead require
2011/6/14 Wei Qin wei@gmail.com
Merge score7 to score.c and remove forwarding functions.
Merge score_handle_option.
Delete score7.c and score7.h.
2011-06-13 Wei Qinwei@gmail.com
* config.gcc (score-*-elf): Remove score7.o.
* config/score/t-score-elf: Likewise.
I think the time has come to obsolete the IRIX 6.5 and Tru64 UNIX V5.1
ports: my test machines are falling apart one by one, bootstraps take
between 24 (osf) and 36 (irix) hours, and both platform's EOSL is
approaching:
* IRIX 6.5 until December 2013:
As just announced, here's the patch to the GCC 4.7 changes.html to
document the IRIX and Tru64 UNIX obsoletions, together with the
-compat-bsd removal.
I don't need approval for the patch, but would be grateful for
improvements to wording.
Thanks.
Rainer
2011-07-01 Rainer Orth
This fixes the fallout of the IPA PTA patch. The
varpool_all_refs_explicit_p predicate does not properly give answers
for external variables. Fixed as follows, pre-approved by Honza on IRC.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-07-01 Richard
- Original Message -
From: Richard Guenther richard.guent...@gmail.com
To: Kai Tietz kti...@redhat.com
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
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, then you
On Fri, Jul 1, 2011 at 1:58 PM, Stubbs, Andrew andrew_stu...@mentor.com 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
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
On Fri, Jul 1, 2011 at 1:44 PM, Kai Tietz kti...@redhat.com wrote:
Ok, here is reworked patch with adjusted testcase.
ChangeLog gcc/
2011-07-01 Kai Tietz kti...@redhat.com
* tree-ssa-forwprop.c (truth_valued_ssa): New function.
(detect_not_expr_operand): New function.
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 has an
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 ja...@redhat.com
Date: Thu Jun 30 23:05:49 2011 -0400
PR c++/49085
* semantics.c
H.J. Lu hjl.to...@gmail.com writes:
On Fri, Jul 1, 2011 at 2:02 AM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
H.J. Lu hjl.to...@gmail.com writes:
Here is the updated patch. It works on simple tests.
I am running full tests. I kept config/i386/value-unwind.h
since
On Fri, Jul 1, 2011 at 6:37 AM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
H.J. Lu hjl.to...@gmail.com writes:
On Fri, Jul 1, 2011 at 2:02 AM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
H.J. Lu hjl.to...@gmail.com writes:
Here is the updated patch. It works on simple tests.
2011/7/1 Richard Guenther richard.guent...@gmail.com:
On Fri, Jul 1, 2011 at 1:44 PM, Kai Tietz kti...@redhat.com wrote:
Ok, here is reworked patch with adjusted testcase.
ChangeLog gcc/
2011-07-01 Kai Tietz kti...@redhat.com
* tree-ssa-forwprop.c (truth_valued_ssa): New function.
2011/7/1 Kai Tietz ktiet...@googlemail.com:
2011/7/1 Richard Guenther richard.guent...@gmail.com:
On Fri, Jul 1, 2011 at 1:44 PM, Kai Tietz kti...@redhat.com wrote:
Ok, here is reworked patch with adjusted testcase.
ChangeLog gcc/
2011-07-01 Kai Tietz kti...@redhat.com
*
H.J. Lu hjl.to...@gmail.com 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
On Fri, Jul 1, 2011 at 7:02 AM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
H.J. Lu hjl.to...@gmail.com 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
On Sun, Jun 19, 2011 at 11:39 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jun 3, 2011 at 5:51 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Fri, Jun 3, 2011 at 5:31 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun 3, 2011 at 6:31 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed,
H.J. Lu hjl.to...@gmail.com 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
Ping ... !
2011/6/28 Janus Weil ja...@gcc.gnu.org:
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
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
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 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
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 unsigned to
On Fri, Jul 1, 2011 at 7:25 AM, Rainer Orth r...@cebitec.uni-bielefeld.de
wrote:
H.J. Lu hjl.to...@gmail.com 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
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, while an u64
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
+++
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)
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're
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
committed
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
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
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.
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 only
H.J. Lu hjl.to...@gmail.com writes:
On Wed, Jun 29, 2011 at 7:06 AM, H.J. Lu hjl.to...@gmail.com wrote:
On Wed, Jun 29, 2011 at 1:45 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
H.J. Lu hongjiu...@intel.com writes:
@@ -706,7 +706,13 @@ precompute_register_parameters (int
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
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
OK.
Jason
On 1 July 2011 17:03, Richard Henderson r...@redhat.com 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[]
On Fri, 01 Jul 2011 18:27:36 +0200, Jason Merrill wrote:
OK.
Checked in:
http://gcc.gnu.org/viewcvs?view=revisionrevision=175761
No regressions on gcc-4.6.1-1.fc15.x86_64 (it is not trunk but hopefully
similar enough).
Thanks,
Jan
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
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
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.
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.
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 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
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
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
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
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't see. Where are
Am 01.07.2011 14:34, schrieb Janne Blomqvist:
On Thu, Jun 30, 2011 at 21:09, Thomas Koenigtkoe...@netcologne.de 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?
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 fine (i.e.
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
On Fri, 1 Jul 2011, Dr. David Alan Gilbert wrote:
+/* For write */
+#include unistd.h
+/* For abort */
+#include stdlib.h
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
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
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
This is indeed a problem. Good catch; thanks!
-DeLesley
On Fri, Jul 1, 2011 at 11:50 AM, Martin Jambor mjam...@suse.cz 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
This patch is OK, I think I have a slight preference for the warning
where it is.
Jason
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,
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 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
a
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.
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 once I'm
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 ja...@redhat.com
Date: Fri Jul 1 13:43:22 2011 -0400
PR c++/48593
* pt.c (tsubst_qualified_id):
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
Replacing assert with error.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e42789795f05e88b0b55c5da0670aa827ad046b2
Author: Jason Merrill ja...@redhat.com
Date: Fri Jul 1 14:06:46 2011 -0400
PR c++/48261
* pt.c (lookup_template_function): Handle non-function.
diff --git
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 ...
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 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
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. Using a
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 float and
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
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 ja...@redhat.com
* tree-object-size.c (pass_through_call): Handle
BUILT_IN_ASSUME_ALIGNED.
---
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
that the
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
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 */
+ tree
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 from
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 ebotca...@adacore.com
*
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
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, come to think
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.
LGTM
On 7/1/11, Gabriel Charette gch...@google.com 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,
On 7/1/11, Gabriel Charette gch...@google.com 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
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
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
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
95 matches
Mail list logo
