Hello!
> > 2012-07-27 Mike Frysinger
> >
> > * md5.c (md5_finish_ctx): Declare swap_bytes. Assign SWAP() output
> > to swap_bytes, and then call memcpy to move it to ctx->buffer.
> >
> >/* Take yet unprocessed bytes into account. */
> > - md5_uint32 bytes = ctx->buflen;
>
*PING*
Tobias Burnus wrote:
TS29113 allows also non interoperable procedures with
c_funloc/c_f_procpointer; hence, this patch allows them with
-std=f2008ts:
"The function C F PROCPOINTER from the intrinsic module ISO C BINDING
has the restriction in ISO/IEC 1539-1:2010 that CPTR and FPTR sha
Steven -
> Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk?
Thanks for working on this. It looks good, couple of minor comments:
Please add an assert that d->have_this_obj == true in
write_types_local_process_field, before the oprintf that outputs
"this_obj".
> @@ -3444,6 +3449
Hi -
> See http://gcc.gnu.org/PR53880#c27
>
> Could you please have a look at that problem, and see if you, with all
> your GTY-fu, see an easy way out?
It looks like you beat me to it :)
--
Laurynas
The TPF assembler supports dwarf4 discriminators, but the TPF
debuggers do not. Ok to apply?
* config/s390/tpf.h (SUPPORTS_DISCRIMINATOR): Define to 0 for TPF.
Index: gcc/config/s390/tpf.h
===
--- gcc/config/s390/tpf.h
Hi,
This patch fixes the source location for automatically generated calls
to deallocator. For example:
19 void foo(int i)
20 {
21 for (int j = 0; j < 10; j++)
22 {
23 t test;
24 test.foo();
25 if (i + j)
26 {
27 test.bar();
28 return;
Hi,
This patch fixed the problem when a LOOP_EXIT edge for the inner loop
happened to target at the LOOP_LATCH of the outer loop. As the outer
loop is processed first, the LOOP_BRANCH heuristic is honored
(first_match), thus the inner loop's trip count is 0. (The attached
unittest demonstrates thi
OK.
Jason
On 07/31/2012 12:42 AM, Jason Merrill wrote:
On 07/30/2012 06:26 PM, Paolo Carlini wrote:
+ if ((cxx_dialect == cxx98)
+ || (TREE_CODE (decl) != FUNCTION_DECL && is_primary))
We shouldn't do this check for non-primary templates in C++98 mode,
either.
Yes. Thus the below also passes tes
Hello,
This PR concerns a huge compile time regression since
-ftrack-macro-expansion=2 became the default. It turns out that
gengtype generates code that is quadratic in the GTY((length)) of
arrays, and in this case (a PCH for a Boost header...) there are 183k
maps for macro expansion line maps in
On 07/30/2012 06:26 PM, Paolo Carlini wrote:
+ if ((cxx_dialect == cxx98)
+ || (TREE_CODE (decl) != FUNCTION_DECL && is_primary))
We shouldn't do this check for non-primary templates in C++98 mode, either.
Jason
On 07/30/2012 02:05 PM, Nathan Froyd wrote:
> * expmed.h (NUM_MODE_VECTOR_INT): Define.
> (struct expmed_op_cheap, struct expmed_op_costs): New structures.
> (struct target_expmed): Convert x_mul_highpart_cost and
> x_mul_widen_cost fields to be indexed by integer modes.
>
Split out s390_two_part_insv from s390_expand_cs_hqi to try
harder to use bit insertion instructions in the CAS loop.
---
gcc/config/s390/s390-protos.h |3 +-
gcc/config/s390/s390.c| 141 ++-
gcc/config/s390/s390.md | 401 +
3
Try RISBG last, after other mechanisms have failed; don't require
operands in registers for it but force them there instead. Try a
limited form of ICM.
---
gcc/config/s390/s390.c | 129 ++-
1 files changed, 82 insertions(+), 47 deletions(-)
diff --git
The atomic_load/storedi_1 patterns are fixed to use LM, STM.
I've had a go at generating better code in the HQImode CAS
loop for aligned memory, but I don't know that I'd call it
the most efficient thing ever. Some of this is due to
deficiencies in other parts of the compiler (including the
s390
Hi,
On 07/30/2012 10:10 PM, Jason Merrill wrote:
On 07/28/2012 11:28 AM, Paolo Carlini wrote:
as the testcase shows (merge of 53624 & 54104), in case of local types
(possibly synthesized for a lambda) we check for the default template
arguments of the synthesized template parameters according t
On 07/30/2012 01:38 PM, Richard Sandiford wrote:
...unfortunately, it doesn't prevent the use floating-point operations.
That's why it's such a bad option. The only difference from the compiler
proper's point of view between -msoft-float and -mno-float is that they
define different preprocessor
On 07/30/2012 01:38 PM, Richard Sandiford wrote:
...unfortunately, it doesn't prevent the use floating-point operations.
That's why it's such a bad option. The only difference from the compiler
proper's point of view between -msoft-float and -mno-float is that they
define different preprocessor
On Mon, 23 Jul 2012, Steven Bosscher wrote:
> In revision 175064 you introduced a new subdirectory: gcc/common.
> This directory is not documented in sourcebuild.texi. Can you please
> add documentation for it?
I've applied this patch to document this directory. Tested with "make
info" and "mak
Now that we can freely change the representation of the cost fields in
struct target_expmed, the patch below does so, by only requiring arrays
to hold enough storage for integer modes and/or vector integer modes,
as appropriate.
default_target_expmed shrinks from ~200KB to ~85KB on
x86_64-unknown-
On 07/28/2012 11:28 AM, Paolo Carlini wrote:
as the testcase shows (merge of 53624 & 54104), in case of local types
(possibly synthesized for a lambda) we check for the default template
arguments of the synthesized template parameters according to the rules
for *types* (instead of those for funct
On Mon, 2012-07-30 at 08:28 -0700, Richard Henderson wrote:
> On 2012-07-29 15:56, Oleg Endo wrote:
> > + "&& can_create_pseudo_p ()"
> > + [(set (match_dup 5) (ashift:SI (match_dup 1) (match_dup 2)))
> > + (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
> > + (set (match_dup 0) (me
On Mon, 30 Jul 2012 12:51:47 +0100
Ramana Radhakrishnan wrote:
>This patch converts the testsuite generator to actually produce
> something more sensible than the current set of tests. It changes
> these to generate the following form for a test instead of the
> previous set of tests.
>
> It
Sandra Loosemore writes:
> The MIPS back end has an option -mno-float that is supported by
> bare-metal configs using the SDE library. However, this option is not
> properly documented in the manual, and MIPS_ARCH_FLOAT_SPEC doesn't know
> about it as one of the explicit floating-point configu
On 30 July 2012 20:16, François Dumont wrote:
> Ok for trunk ?
OK, thanks.
Even if it doesn't make any difference after preprocessing the
attached patch fix the closure order in definition of
_GLIBCXX_END_NAMESPACE_* macros.
2012-07-30 François Dumont
* include/bits/c++config (_GLIBCXX_END_NAMESPACE_CONTAINER): Fix
order of closures.
(_GLIBCXX_END_N
On Thu, Jul 19, 2012 at 1:39 PM, Jason Merrill wrote:
>
> On 07/10/2012 03:14 PM, Sriraman Tallam wrote:
>>
>> I am using the questions you asked previously
>> to explain how I solved each of them. When working on this patch, these
>> are the exact questions I had and tried to address it.
>>
>> *
This fixes the de-canonicalization of commutative GIMPLE operations in
the vectorizer that occurs when processing reductions. A loop_vec_info
is flagged for cleanup when a de-canonicalization has occurred in that
loop, and the cleanup is done when the loop_vec_info is destroyed.
Bootstrapped on p
On 07/30/2012 08:40 AM, Ulrich Weigand wrote:
>> > I presume a good test case to examine for ICM is with such an operand
>> > coming from a global. What about STCM? I don't see the output from
>> > sync_compare_and_swap ever being allowed in memory...
> Actually, it's only ICM that is of interest
The MIPS back end has an option -mno-float that is supported by
bare-metal configs using the SDE library. However, this option is not
properly documented in the manual, and MIPS_ARCH_FLOAT_SPEC doesn't know
about it as one of the explicit floating-point configuration changes
that should overri
Hi,
On Mon, 30 Jul 2012, Richard Guenther wrote:
>
> This makes into-SSA no longer rely on variable annotations and instead
> uses on-the-side information local to into/update-SSA. Lookups can
> probably be avoided in some places if we pass around the auxiliar
> information instead of looking i
On 07/30/2012 03:18 PM, Julian Brown wrote:
> There are two issues in play here:
>
> 1. Exception-handling is handled in a target-specific way for ARM,
> defined in the EHABI document ("Exception handling ABI for the ARM
> architecture", IHI 0038A). However, no mention of "forced unwinding" is
> m
Committed as obvious.
Tested on hppa2.0w-hp-hpux11.11 and hppa-unknown-linux-gnu.
Dave
--
J. David Anglin dave.ang...@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
2012-07-30 John David Anglin
PR middl
Richard Henderson wrote:
> On 2012-07-30 07:09, Ulrich Weigand wrote:
> > This seems to disable use of ICM / STCM to perform byte or
> > aligned halfword access. Why is this necessary? Those operations
> > are supposed to provide the required operand consistency ...
>
> Because MEM_P for cmp and
On Mon, 30 Jul 2012, Tom Tromey wrote:
> > "Joseph" == Joseph S Myers writes:
>
> Joseph> On Mon, 30 Jul 2012, Tom Tromey wrote:
> >> 6.3 is about conversions, and the first paragraph starts "several
> >> operators convert ...". Based on this, and other such phrases in the
> >> text, I thin
On 2012-07-27 16:21, Nathan Froyd wrote:
> * defaults.h (GO_IF_MODE_DEPENDENT_ADDRESS): Delete.
> * targhooks.c (default_mode_dependent_address_p): Delete code
> for GO_IF_MODE_DEPENDENT_ADDRESS.
> * system.h (GO_IF_MODE_DEPENDENT_ADDRESS): Poison.
> * doc/tm.texi.in (
On 2012-07-29 15:56, Oleg Endo wrote:
> + "&& can_create_pseudo_p ()"
> + [(set (match_dup 5) (ashift:SI (match_dup 1) (match_dup 2)))
> + (set (match_dup 6) (plus:SI (match_dup 5) (match_dup 3)))
> + (set (match_dup 0) (mem:SI (plus:SI (match_dup 6) (match_dup 4]
Don't create new mems l
This change adds a special case to Get_Socket_Option and Set_Socket_Option
to account for a deviation of Windows' behaviour with respect to the
standard sockets API: on that target, SO_RCVTIMEO and SO_SNDTIMEO expect
a DWORD containing a milliseconds count, not a struct timeval, and furthermore
if
On Mon, Jul 30, 2012 at 5:05 PM, Steven Bosscher wrote:
> On Mon, Jul 30, 2012 at 4:53 PM, Richard Guenther
> wrote:
>> No, but less space efficient and of comparable speed as sbitmap which
>> is also O(1).
>
> But iterating an sbitmap has worse complexity than sparseset.
Which is why I mentione
This change fixes the circuitry that passes binder flags from gnatmake:
for some switches, relative path arguments are changed to absolute paths.
However, for gnatbind the -A switch must not undergo this transformation.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-07-30 Thomas Quinot
On Mon, Jul 30, 2012 at 5:14 PM, Richard Guenther
wrote:
> On Mon, Jul 30, 2012 at 5:05 PM, Steven Bosscher
> wrote:
>> On Mon, Jul 30, 2012 at 4:53 PM, Richard Guenther
>> wrote:
>>> No, but less space efficient and of comparable speed as sbitmap which
>>> is also O(1).
>>
>> But iterating an
This patch implements a new lock-free restriction. Thus, implicit dereferences
of access values prevent, as well as explicit dereference, the lock-free
implementation of protected objects.
The test below illustrates the new lock-free restriction:
-- Source --
generic
On 2012-07-30 07:09, Ulrich Weigand wrote:
> Richard Henderson wrote:
>
>> Tested only as far as cross-compile. I had a browse through
>> objdump of libatomic for a brief sanity check.
>>
>> Can you please test on real hw and report back?
>
> I'll run a test, but a couple of things I noticed:
>
On Mon, Jul 30, 2012 at 4:53 PM, Richard Guenther
wrote:
> No, but less space efficient and of comparable speed as sbitmap which
> is also O(1).
But iterating an sbitmap has worse complexity than sparseset.
Ciao!
Steven
On Mon, Jul 30, 2012 at 4:43 PM, Peter Bergner wrote:
> On Fri, 27 Jul 2012 15:40:35 +0200 Richard Guenther
> wrote:
>> Also it looks less efficient than sbitmap in the case when
>> your main operation is adding to the set and querying the set randomly.
>
> How so? Adding/deleting a member to a
> "Joseph" == Joseph S Myers writes:
Joseph> On Mon, 30 Jul 2012, Tom Tromey wrote:
>> 6.3 is about conversions, and the first paragraph starts "several
>> operators convert ...". Based on this, and other such phrases in the
>> text, I think the entire section applies to operators.
Joseph>
On Fri, 27 Jul 2012 15:40:35 +0200 Richard Guenther
wrote:
> Also it looks less efficient than sbitmap in the case when
> your main operation is adding to the set and querying the set randomly.
How so? Adding/deleting a member to a sparseset is an O(1) operation,
as is querying whether somethin
Richard Guenther wrote:
> On Fri, Jul 27, 2012 at 5:24 PM, Ulrich Weigand wrote:
> > OK for mainline?
>
> Ok. Please add to the documentation that the default vector alignment
> has to be a power-of-two multiple of the default vector element alignment.
Committed, thanks. The documentation now
On Mon, 30 Jul 2012, Tom Tromey wrote:
> 6.3 is about conversions, and the first paragraph starts "several
> operators convert ...". Based on this, and other such phrases in the
> text, I think the entire section applies to operators.
6.3.2.1 paragraphs 2 and 3 are phrased in terms of operators
This makes into-SSA no longer rely on variable annotations and instead
uses on-the-side information local to into/update-SSA. Lookups can
probably be avoided in some places if we pass around the auxiliar
information instead of looking it up all the time.
Bootstrapped and tested on x86_64-unknown
Hi,
I've been investigating a patch which we've been using locally to fix
an issue with backtraces (using, e.g., glibc's backtrace() function)
through C++ exception-handling constructs on ARM. The original author of
the patch was Daniel Jacobowitz (please correct me if my understanding
is wrong!).
Richard Henderson wrote:
> Tested only as far as cross-compile. I had a browse through
> objdump of libatomic for a brief sanity check.
>
> Can you please test on real hw and report back?
I'll run a test, but a couple of things I noticed:
>/* Shift the values to the correct bit positions.
On Mon, Jul 30, 2012 at 2:41 PM, Laurynas Biveinis
wrote:
> I only remembered to add DEF_VEC_A handlgin to gengtype.c a second after
> committing the previous patch [1].
>
> Here it is, done as a follow up. With some luck, this will be short-lived
> code because of the C++ conversion.
Hello Lau
>
> OK with that change.
Thanks a lot!
Checked into the trunk: http://gcc.gnu.org/ml/gcc-cvs/2012-07/msg00878.html
Thanks, K
> "Joseph" == Joseph S Myers writes:
Tom> I wasn't really aware of 6.3.2.1, but after reading it and re-reading
Tom> 6.5.1.1, I think I agree with his "model 0" interpretation: no promotion
Tom> or conversion.
Tom> I don't have a standards-based reason for this, though; just my belief
Tom> t
On Mon, Jul 30, 2012 at 2:05 PM, Kirill Yukhin wrote:
> ChangeLog entry:
> 2012-07-25 Kirill Yukhin
> Michael Zolotukhin
>
> * common/config/i386/i386-common.c (OPTION_MASK_ISA_RDSEED_SET): New.
> (OPTION_MASK_ISA_RDSEED_UNSET): Likewise.
> (ix86_handle_op
On Mon, Jul 30, 2012 at 2:05 PM, Kirill Yukhin wrote:
>> Ehm ...
>>
>>> * gcc.target/i386/sse-13.c: Ditto.
>>> * gcc.target/i386/sse-14.c: Ditto.
>>> * g++.dg/other/i386-2.C: Ditto.
>>> * g++.dg/other/i386-3.C: Ditto.
> Sorry, what's wrong here?
Not here, but abov
I only remembered to add DEF_VEC_A handlgin to gengtype.c a second after
committing the previous patch [1].
Here it is, done as a follow up. With some luck, this will be short-lived code
because of the C++ conversion.
Bootstrapped and regtested on x86_64 linux. OK for trunk?
2012-07-30 Lauryn
> Ehm ...
>
>> * gcc.target/i386/sse-13.c: Ditto.
>> * gcc.target/i386/sse-14.c: Ditto.
>> * g++.dg/other/i386-2.C: Ditto.
>> * g++.dg/other/i386-3.C: Ditto.
Sorry, what's wrong here?
> I suggest you implement handling of this builtin in the same way
> rdrand_1 is i
Hi,
This is similar to the previous patch except that it prevents
(vec_select:DI (operand:DI)) type operations.
Exposed by the vst*_lane*.c tests in the new testsuite.
regards,
Ramana
2012-07-27 Ramana Radhakrishnan
* config/arm/neon.md (neon_vst1_lanedi): Split from ..
(neo
On 30 July 2012 12:41, Ramana Radhakrishnan
wrote:
> Patch 5 - Bug fix that fixes up a set of ICEs because we were always
> generating vec_duplicate of DImode values into other DImode values.
> Possibly needs backporting to older versions.
The recent changes to the vld1_dup intrinsics ended up
On 30 July 2012 12:41, Ramana Radhakrishnan
wrote:
> Hi,
> I've been working on a small project to improve neon intrinsic
> and I kept getting bothered by random failures in gcc.target/arm/neon
> and I got sufficiently irritated that I decided to clean that bit up
> and then found myself in
Hi,
lower-subreg.c goes completely bonkers at times with code
that uses the large vector modes, especially the vld3 / vst3
type operations. In these cases these large modes are usually
split into SImode moves which then cause massive spilling
and in these cases we end up generating really really b
> Patch 2 is a bug fix that fixes up the splitters so that they take
> into account the right register for the right mode . For instance a
> register not fit for a TImode value shouldn't be put in one even if
> the larger mode allows a different register . This is possible for
> OImode values or in
> Patch 1 fixes up the vaba and vabal patterns to use a canonical RTL
> form with the first operand to the plus being the more complex one.
This patch canonicalizes the instruction patterns for the
vaba and vabal intrinsics so that the more complex operand
to plus is the first operand. This preven
Hi,
I've been working on a small project to improve neon intrinsic
and I kept getting bothered by random failures in gcc.target/arm/neon
and I got sufficiently irritated that I decided to clean that bit up
and then found myself in a maze of rabbit holes. I've always been
somewhat bothered by
On 28 July 2012 10:26, Marc Glisse wrote:
> On Mon, 18 Jun 2012, Ramana Radhakrishnan wrote:
>
>> This patch following on from the fix for turning on __builtin_shuffle
>> for c++ , enables folding of vec_perm_exprs in the front-end for
>> constexpr and constructor style values.
>
>
> Hello,
>
> I
On Fri, 27 Jul 2012, Richard Guenther wrote:
>
> This avoids triggering update-ssa right after into-ssa just because
> we didn't rename virtual operands yet. Simply do that on-the-fly,
> update_stmt will have added bare symbols as operands already.
> Surprisingly simple ... no idea why I chose t
On Fri, Jul 27, 2012 at 5:24 PM, Ulrich Weigand wrote:
> Richard Guenther wrote:
>> On Mon, Jun 11, 2012 at 5:25 PM, Richard Earnshaw wrote:
>> > On 11/06/12 15:53, Richard Guenther wrote:
>> >> The type argument or the size argument looks redundant.
>> >
>> > Technically, yes, we could get rid o
Hello,
with this move to t-bpabi other targets like RTEMS profit also from this
change. This is very good since the unwinder pull-in for 64-bit divisions was
pretty bad for small Cortex-M3 systems with internal flash only.
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 3
70 matches
Mail list logo
