On Thu, 30 Jan 2014, Jakub Jelinek wrote:
> On Thu, Jan 30, 2014 at 07:25:03PM +0100, Richard Biener wrote:
> > *** 8886,8891
> > --- 8892,8932
> > || TREE_ADDRESSABLE (desttype))
> > return NULL_TREE;
> >
> > + /* Make sure we are not copying using a floating-point mo
On Thu, 30 Jan 2014, Marc Glisse wrote:
> On Thu, 30 Jan 2014, Richard Biener wrote:
>
> >/* Associate (p +p off1) +p off2 as (p +p (off1 + off2)). */
> >ptr = gimple_assign_rhs1 (stmt);
> >off1 = gimple_assign_rhs2 (stmt);
> > ! if (TREE_CODE (ptr) != SSA_NAME
> > ! || !has_
On Thu, 30 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs on arm, because ifcvt decides to conditionalize
> a frame related instruction that restores a call saved register and adjusts
> stack pointer (== CFA) in order to merge shrink-wrapped and
> non-shrink-wrapped basic bl
On Thu, 30 Jan 2014, Cong Hou wrote:
> Hi
>
> PR6 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6) is caused by
> GCC vectorizer. The bug appears when handling vectorization patterns. When
> a pattern statement has additional new statements stored in pattern_def_seq
> in vect_transform_loo
On Thu, Jan 30, 2014 at 9:47 PM, Jakub Jelinek wrote:
> On Thu, Jan 30, 2014 at 08:27:47PM +, Paulo Matos wrote:
>> Yes, it looks strange but it was the way we came up with to
>> implement an instruction that loads from a pair of addresses.
>>
>> From what I wrote previously to Richard.
>> "We
On 30 Jan 19:24, Uros Bizjak wrote:
> On Thu, Jan 30, 2014 at 5:41 PM, Ilya Tocar wrote:
>
> > This patch removes possible division by zero.
> > Make check passes. Ok for trunk?
> >
> > 2014-01-30 Ilya Tocar
> >
> > * gcc.target/i386/m512-check.h: Use correct rounding values.
> >
> > -
Hello,
While testing PR 58960 on ia64, I've enabled selective scheduling for
bootstrap and found two small issues. One is the other instance of PR
57662 and another one is a miscompile that happens because we emit an insn
with INSN_DELETED_P flag set; the insn then obviously does not get outp
On Fri, Jan 31, 2014 at 11:00 AM, Ilya Tocar wrote:
>> > This patch removes possible division by zero.
>> > Make check passes. Ok for trunk?
>> >
>> > 2014-01-30 Ilya Tocar
>> >
>> > * gcc.target/i386/m512-check.h: Use correct rounding values.
>> >
>> > ---
>> > gcc/testsuite/gcc.targ
Often enough I need to print expanded_location of location_t.
It'd be convenient to have this macro in gdbinit.in.
Ok?
2014-01-31 Marek Polacek
* gdbinit.in (pel): Define.
diff --git a/gcc/gdbinit.in b/gcc/gdbinit.in
index c388f8a..25c530a 100644
--- a/gcc/gdbinit.in
+++ b/gcc/gdbini
Hi Thomas!
I fixed these patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01520.html .
Instead of adding new OACC_* data structures and macros for OpenACC
clauses these patches reuse existing OMP_* functionality and extends it.
But OpenACC-specific constructs and directives still named
OpenACC 1.0 support to fortran FE -- core.
gcc/fortran/
* dump-parse-tree.c
(show_omp_node): Dump also OpenACC executable statements.
(show_code_node): Call it.
* gfortran.h
(ST_OACC_PARALLEL_LOOP, ST_OACC_END_PARALLEL_LOOP, ST_OACC_PARALLEL,
ST_OACC_END_PARALLEL,
OpenACC 1.0 fortran FE support -- matching and resolving.
* openmp.c (gfc_free_omp_clauses): Remove also OpenACC clauses.
(gfc_free_exprlist): New function to clear expression list.
(match_oacc_exprlist): New function to match expression list.
(match_oacc_clause_gang): New fun
OpenACC 1.0 fortran FE support -- translation to GENERIC.
* trans-decl.c
(gfc_generate_function_code): Insert OACC_DECLARE GENERIC node.
* trans-openmp.c (gfc_convert_expr_to_tree): New helper function.
(gfc_trans_omp_array_reduction): Support also OpenACC. Add parameter.
OpenACC 1.0 support -- GENERIC nodes and gimplify stubs.
gcc/
* gimplify.c (is_gimple_stmt): Stub OpenACC directives and clauses.
(gimplify_scan_omp_clauses, gimplify_adjust_omp_clauses): Likewise.
(gimplify_expr): Likewise.
* omp-low.c (scan_sharing_clauses): Likewise.
OpenACC 1.0 fortran FE support -- tests.
gcc/testsuite/gfortran.dg/goacc/
* goacc.exp: New test directory.
* branch.f95: New test.
* continuation-free-form.f95: Likewise.
* data-clauses.f95: Likewise.
* data-tree.f95: Likewise.
* declare-1.f95: Likewise.
* decl
OpenACC 1.0 support -- documentation.
gcc/doc/
* generic.texi: Document OACC_KERNELS, OACC_DATA, OACC_HOST_DATA,
OACC_DECLARE, OACC_UPDATE, OACC_ENTER_DATA, OACC_EXIT_DATA, OACC_WAIT,
OACC_CACHE.
>From 2550374183627d221f8881d14939ea7b0045bfba Mon Sep 17 00:00:00 2001
From: Ilm
On Fri, Jan 31, 2014 at 03:10:59PM +0400, Ilmir Usmanov wrote:
> @@ -1182,6 +1281,26 @@ show_omp_node (int level, gfc_code *c)
> {
> switch (list_type)
> {
> + case OMP_LIST_COPY: type = "COPY"; break;
> + case OMP_LIST_OACC_COPYIN: type = "COPYIN
Hi!
Apparently tsan doesn't work e.g. under setarch x86_64 -R, at which point
all tests fail. This patch just disables the tests in that case.
Tested on x86_64-linux both under setarch x86_64 -R and without, committed
to trunk as obvious.
Of course it would be nicer if libtsan actually supporte
Hi Jakub!
Thank you for review and quick answer.
The above are OpenACC specific clauses, so they should have OACC_LIST_*?
I just followed Thomas's style recomendations:
If we're adding new names for implementing OpenACC things, maybe we
should also name these OMP_*, to keep things simple to re
Jakub Jelinek writes:
> --- gcc/ifcvt.c.jj2014-01-09 08:20:55.0 +0100
> +++ gcc/ifcvt.c 2014-01-29 17:16:29.912259159 +0100
> @@ -338,6 +338,10 @@ cond_exec_process_insns (ce_if_block *ce
>
>gcc_assert (NONJUMP_INSN_P (insn) || CALL_P (insn));
>
> + /* dwarf2out
Hi,
in this ICE on invalid regression we emit a sensible error message about
the duplicate base and then we ICE when we process the function, because
TYPE_VFIELD (type) is null in build_vfield_ref. My changes just check
for the offending situation and return early from build_base_path
(fold_b
> >> We won't get zero from exponential function, so expecting zero result
> >> is flawed anyway.
> >>
> >> If we would like to introduce universal epsilon comparisons into the
> >> testsuite, then please read [1]. Being overly pedantic, the definition
> >> should be "|(v[i] - u.a[i]) / v[i]|", as
ping, adding build maintainers
Am 10.01.2014 12:06, schrieb Matthias Klose:
> Am 10.01.2014 10:49, schrieb Zhenqiang Chen:
>> On 10 January 2014 17:23, Matthias Klose wrote:
>>> Am 10.01.2014 09:23, schrieb Zhenqiang Chen:
Hi,
MULTIARCH_DIRNAME was removed @r196649 since the dir in
On Fri, Jan 31, 2014 at 1:32 PM, Ilya Tocar wrote:
>> >> We won't get zero from exponential function, so expecting zero result
>> >> is flawed anyway.
>> >>
>> >> If we would like to introduce universal epsilon comparisons into the
>> >> testsuite, then please read [1]. Being overly pedantic, the
On Fri, Jan 31, 2014 at 12:34:46PM +0100, Jakub Jelinek wrote:
> Apparently tsan doesn't work e.g. under setarch x86_64 -R, at which point
> all tests fail. This patch just disables the tests in that case.
>
> Tested on x86_64-linux both under setarch x86_64 -R and without, committed
> to trunk a
On Fri, Jan 31, 2014 at 09:41:59AM +0100, Richard Biener wrote:
> Is that because si and pattern_def_si point to the same stmts? Then
> I'd prefer to do
>
> if (is_store)
>{
> ...
> pattern_def_seq = NULL;
>}
> else if (!transform_pattern_stmt && gsi_end_p (pattern_def_si))
>
On Thu, 30 Jan 2014, Walter Lee wrote:
> Here is a release note item for big endian support on tilegx. Ok to
> commit once that change is approved?
Yes. If you like, you could also mention the new command-line
options or if there is anything around configuration options.
And as maintainer of t
On Fri, 31 Jan 2014, Jakub Jelinek wrote:
> On Fri, Jan 31, 2014 at 12:34:46PM +0100, Jakub Jelinek wrote:
> > Apparently tsan doesn't work e.g. under setarch x86_64 -R, at which point
> > all tests fail. This patch just disables the tests in that case.
> >
> > Tested on x86_64-linux both under
Hi,
For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128,
-mlong-double-64 and -mlong-double-80 negate each other so that the
last one
On Fri, Jan 31, 2014 at 02:57:14PM +0100, Richard Biener wrote:
> Ok (you remove one target selector - was that spurious)
Yes, tsan is supported on x86_64-linux only anyway, so tsan_init
fails everywhere else.
Jakub
2014-01-28 Jason Merrill :
> On 01/27/2014 04:28 PM, Fabien Chêne wrote:
>>
>> + if (DECL_DEPENDENT_P (decl) && USING_DECL_TYPENAME_P (decl))
>> +{
>> + /* We have found a type introduced by a using
>> +declaration at class scope that refers to a dependent
>> +type.
>> +
>
On Fri, Dec 13, 2013 at 10:47 PM, FX wrote:
>> The patch is okay, but if other architecture maintainers could add
>> similar checks for their ports (SPARC and PPC, I guess), it would be nice.
>
> Thanks, committed as rev. 205975
>
> Adding other systems to the list of checks will be easy, once the
On Fri, Jan 31, 2014 at 3:33 PM, Richard Biener
wrote:
> On Fri, Dec 13, 2013 at 10:47 PM, FX wrote:
>>> The patch is okay, but if other architecture maintainers could add
>>> similar checks for their ports (SPARC and PPC, I guess), it would be nice.
>>
>> Thanks, committed as rev. 205975
>>
>> A
On Fri, Jan 31, 2014 at 3:40 PM, Richard Biener
wrote:
> On Fri, Jan 31, 2014 at 3:33 PM, Richard Biener
> wrote:
>> On Fri, Dec 13, 2013 at 10:47 PM, FX wrote:
The patch is okay, but if other architecture maintainers could add
similar checks for their ports (SPARC and PPC, I guess), i
> I've just seen that an explicit --enable-multilib is a way to do that.
Yes, I was writing that as a reply when I received your email. (Also, it’s
written in the configure error message.)
> Btw, doing the configure check exactly after all-stage1-gcc should be
> an early enough and a serializat
On Fri, Jan 31, 2014 at 3:45 PM, FX wrote:
>> I've just seen that an explicit --enable-multilib is a way to do that.
>
> Yes, I was writing that as a reply when I received your email. (Also, it's
> written in the configure error message.)
Yeah - you know, that message is quite long and somehow I
On 2014.01.31 at 07:22 +0100, Jan Hubicka wrote:
> +tree
> +vtable_pointer_value_to_binfo (tree t)
> +{
> + /* We expect &MEM[(void *)&virtual_table + 16B].
> + We obtain object's BINFO from the context of the virtual table.
> + This one contains pointer to virtual table represented via
>
Hello Everyone,
Did anyone get a chance to look at this patch (link to patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01612.html)? I tried to do as
Jakub mentioned but it hits a road-block when it comes to iterators due to
variable scoping issues.
This patch does not disru
We were failing to set TARGET_EXPR_LIST_INIT_P on a TARGET_EXPR created
from aggregate initialization, which is needed to avoid calling the copy
constructor when using that TARGET_EXPR to initialize the element of the
underlying array of the initializer_list.
We also should avoid building a CO
We need to loosen the check for an exact match when we're doing partial
ordering, because dealing with dependent types means we can't
instantiate things like typenames to see what they end up being. And
it's not necessary because when we've gotten to partial ordering, we
already know that both
This patch fixes a problem in the compiler of confusing references
with modifications in the xref listing. This is now fixed properly.
The following program
1. procedure TooManyXrefs is
2.type r is record
3. a : integer;
4.end record;
5.type v is array (1
The package s-tposen is used to implement protected objects (with one entry)
in the ravenscar profile. In fact, only a subset of the ravenscar profile
is required to trigger the use of this package (instead of s-tpoben). This
patch adds a restriction to the triggering conditions, in order to simpli
> As I said, you can't "properly" check it at the point you are checking.
> Which is why I complain - you're not checking this properly!
This is understood. There is a choice to be made, between an early check (which
will benefit our casual users) catching this particular special case, and a
lat
On Wed, Jan 29, 2014 at 10:58:55PM +, Iyer, Balaji V wrote:
> This is the testcase I am using:
>
> _Cilk_for (vector::iterator iter = array.begin(); iter != array.end();
> iter++)
> {
>if (*iter == 6)
> *iter = 13;
> }
>
This patch corrects the treatment of a deallocation call where the designated
type is class-wide and also acts as a generic actual in an instantiation, to
perform a runtime check when trying to determine the controlled-ness of the
deallocated object.
-- Source --
-- dea
This patch adds a warning to a barrier function in an entry body, when the
barrier mentions data that is not private to the protected object, and subject
to external modification by unsynchronized actions, which can lead to hard-to-
diagnose race conditions.
Compiling entry_with_global_barrier.adb
On Fri, Jan 31, 2014 at 04:42:57PM +0100, Jakub Jelinek wrote:
> Can you explain why you emit anything in between the parallel and _Cilk_for?
> I don't see why it should be needed.
> Depending on what the Cilk+ standard allows you to do (can array.begin ()
> be evaluated multiple times or not, and
OK.
Jason
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Friday, January 31, 2014 11:04 AM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Issue with _Cilk_for
>
> On Fri, Jan 31, 2014 at 04:42:57PM +0100, Jakub Jelinek wrote:
> > Can you explain why
Here we were leaving DECL_EXTERNAL set on the TLS init alias, so it
wasn't getting emitted properly.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit e0343cda07dc6b8139eeb7c3a5f25891d48a6300
Author: Jason Merrill
Date: Fri Jan 31 10:54:49 2014 -0500
PR c++/55800
* decl
On Fri, Jan 31, 2014 at 04:18:28PM +, Iyer, Balaji V wrote:
> I tried to do this. The thing is, you had me model like this:
>
> #pragma omp parallel for
> _Cilk_for (...)
> {
> Body
> }
>
> Now, the compiler will do something like this:
>
> #pragma OMP parallel
> {
> #pragma Omp
On Fri, Jan 31, 2014 at 2:59 PM, H.J. Lu wrote:
> For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
> This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
> Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128,
> -mlong-double-64 and -m
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jakub Jelinek
> Sent: Friday, January 31, 2014 11:26 AM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: Issue with _Cilk_for
>
> On Fri, Jan 31, 2014 at 04:
On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
> Hi,
>
> For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
> This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
> Bionic. I only added MASK_LONG_DOUBLE_128. I made -mlong-double-128,
> -mlong-double-64
On Fri, Jan 31, 2014 at 8:52 AM, Uros Bizjak wrote:
> On Fri, Jan 31, 2014 at 2:59 PM, H.J. Lu wrote:
>
>> For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
>> This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
>> Bionic. I only added MASK_LONG_DOUBL
On Fri, Jan 31, 2014 at 5:58 PM, Andrew Pinski wrote:
> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
>> Hi,
>>
>> For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
>> This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
>> Bionic. I only added MASK_
On Fri, Jan 31, 2014 at 9:04 AM, Uros Bizjak wrote:
> On Fri, Jan 31, 2014 at 5:58 PM, Andrew Pinski wrote:
>> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
>>> Hi,
>>>
>>> For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
>>> This patch adds -mlong-double-128 to i386 an
Hi,
I think we can pretty easily fix the remaining minor issue in the
thread_local meta-bug: the ICE happens because, after the error, we end
up calling cgraph_same_body_alias from handle_tls_init with a null
second argument (returned by get_tls_init_fn), thus
cgraph_create_function_alias cra
In this testcase, an error caused us to decide that a variable needs
initialization but not a TLS init function. We should handle that
gracefully.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit cc60625316aa72c2142bd90a30e3756358caac23
Author: Jason Merrill
Date: Fri Jan 31 11
Oops, sorry I was slow to claim this PR...
Jason
On Jan 31, 2014, at 2:40 AM, Marek Polacek wrote:
> Often enough I need to print expanded_location of location_t.
> It'd be convenient to have this macro in gdbinit.in.
>
> Ok?
Looks good to me…
> I've tested your patch a little bit and hit the gcc_assert above:
>
> markus@x4 tmp % cat test.ii
> class A {
> public:
> unsigned length;
> };
> class B {};
> class MultiTermDocs : public virtual B {
> protected:
> A readerTermDocs;
> A subReaders;
> virtual B *m_fn1(int *);
> virtual
On Fri, 31 Jan 2014, Andrew Pinski wrote:
> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
> > Hi,
> >
> > For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
> > This patch adds -mlong-double-128 to i386 and makes it default for 64-bit
> > Bionic. I only added MASK_LONG_DO
On 01/29/2014 12:49 PM, Paolo Carlini wrote:
By the way,
this recycling of TEMPLATE_TYPE_PARM + name seems weird to me too, I
noticed it a couple of times already (I think it shows in an open
diagnostic issue too). I think the alternative would an additional
TREE_CODE and a lot of uses of it wher
On Fri, 31 Jan 2014, Richard Biener wrote:
> Still I think this is odd behavior - as you are matching x86_64-*linux
> you can as well check for /usr/include/gnu/stub{,-64}.h. I don't know
On Ubuntu those are in /usr/include/x86_64-linux-gnu/gnu/ (and I suppose
the 32-bit one is /usr/include/i38
On Fri, Jan 31, 2014 at 10:12 AM, Joseph S. Myers
wrote:
> On Fri, 31 Jan 2014, Andrew Pinski wrote:
>
>> On Fri, Jan 31, 2014 at 5:59 AM, H.J. Lu wrote:
>> > Hi,
>> >
>> > For 64-bit Android, long double is 128-bit IEEE-754 floating point type.
>> > This patch adds -mlong-double-128 to i386 and
OK, thanks.
Jason
In the discussion of PR 59469, Honza said that the C++ front end should
be setting forced_by_abi on explicitly instantiated decls. This patch
does that, though unfortunately it does not seem to be sufficient to fix
the bug.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 2c704f89487f0df
It seems that lower_try_finally_switch was not properly updated for the
addition of EH_ELSE. We tried to lower the finally construct before we
actually handled the EH_ELSE construct specially.
I examined the other lower_try_finally_* alternatives and they all seem to do
the right thing.
Testing
Hi,
Similar to other architectures, failing to set TRY_EMPTY_VM_SPACE
results in a Segmentation Fault and ICE in cc1plus when using
precompiled headers and randomize_va_space is set. This patch fixes the
issue, and now I can reliably build packages which use pch (wxGTK and
openjdk in particular wo
Hi,
this is variant of testcase that produces wrong code on Mainline.
$ ./xgcc -B ./ -O3 ~/t.C -S -fno-partial-inlining -fno-early-inlining
-fdump-ipa-all ; g++ t.s; ./a.out
Aborted
The bug is that we determine wrong type on call of ~MultiTermDocs within ~C (it
is determined as C, while it reall
Hi,
> On 31/gen/2014, at 18:32, Jason Merrill wrote:
>
> Oops, sorry I was slow to claim this PR...
No problem, nice to see the bug going completely away!
Well, you may want to have a look to my pending work on c++/51219 ;)
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01693.html
http://gc
Hi!
As described in the PR, __builtin_setjmp_receiver isn't declared to
returns_twice, and thus after dce cfun->calls_setjmp might be no longer true.
At RTL __builtin_setjmp_receiver is handled as non-local label, so this
patch just forces cfun->has_nonlocal_label already in GIMPLE, so that
e.g. t
Hi!
Without this patch, cprop can propagate e.g. a SYMBOL_REF to former
(mem (plus (reg) (const_int)))
making it invalid RTL (as plus of CONSTANT_P arguments must be simplified
or surrounded by CONST).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?
2014-01-31
On Fri, Jan 31, 2014 at 11:59 AM, Kyle McMartin wrote:
> Hi,
>
> Similar to other architectures, failing to set TRY_EMPTY_VM_SPACE
> results in a Segmentation Fault and ICE in cc1plus when using
> precompiled headers and randomize_va_space is set. This patch fixes the
> issue, and now I can reliab
Hi,
here is even better testcase (in a sense that my patch does not solve the wrong
code issue)
Compile with ./xgcc -B ./ -O3 ~/t.C -S -fno-partial-inlining
-fno-early-inlining -fdump-ipa-all -fdump-tree-all -fipa-cp -fno-ipa-sra
Here the sequence is bit different. Here we have contstruction t
On Fri, Jan 31, 2014 at 02:03:25PM -0800, Andrew Pinski wrote:
> > 2014-01-31 Kyle McMartin
> >
> > PR pch/60010
> > * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64.
>
>
> If this gets merged before my ILP32 changes, I will make sure I
> include a fix for ILP32 al
Committed to branch dmalcolm/jit:
The libgccjit C API is relatively low-level and thus should be easy to
maintain a stable ABI for, and to wrap from many different languages.
However, it's rather verbose.
This commit adds an example of a C++ wrapper, which makes use of methods,
overloading, and
On Fri, Jan 31, 2014 at 2:09 PM, Kyle McMartin wrote:
> On Fri, Jan 31, 2014 at 02:03:25PM -0800, Andrew Pinski wrote:
>> > 2014-01-31 Kyle McMartin
>> >
>> > PR pch/60010
>> > * config/host-linux.c (TRY_EMPTY_VM_SPACE): Define for AArch64.
>>
>>
>> If this gets merged before my
On 01/28/2014 01:37 PM, Paolo Carlini wrote:
... by the way, I don't understand why we are appending the constructor
at all for the unnamed bit-field?!? Eg, what about the below?
I agree, it doesn't seem necessary; output_constructor deals fine with a
sparse CONSTRUCTOR. This patch is OK.
J
Hi Rong, while building for arm toolchain on chromeos, GCOV_LOCKED is
not defined, which leads to redefinition of cs_all, this is observed
on google/gcc-4_8 branch.
Patch below, tested on chromeos for arm and x86_64 arch.
Ok for google/gcc-4_8 branch?
diff --git a/libgcc/libgcov-driver.c b/libgc
On Fri, Jan 31, 2014 at 5:06 AM, Jakub Jelinek wrote:
>
> On Fri, Jan 31, 2014 at 09:41:59AM +0100, Richard Biener wrote:
> > Is that because si and pattern_def_si point to the same stmts? Then
> > I'd prefer to do
> >
> > if (is_store)
> >{
> > ...
> > pattern_def_seq = NULL;
> >
Hi,
One more patch in the set supporting -maltivec=be for the Altivec
builtins, this one for vec_perm. Most of the work was done already in
rs6000.c:altivec_expand_vec_perm_le (). We can reuse this logic for the
present work by generalizing the code to operate on vector types other
than V16QImod
Thanks for catching this, and the fix.
OK for google branch.
-Rong
On Fri, Jan 31, 2014 at 2:46 PM, Hán Shěn (沈涵) wrote:
> Hi Rong, while building for arm toolchain on chromeos, GCOV_LOCKED is
> not defined, which leads to redefinition of cs_all, this is observed
> on google/gcc-4_8 branch.
>
>
On Jan 9, 2014, at 7:20 AM, Richard Biener wrote:
> @@ -968,7 +968,7 @@ get_polymorphic_call_info (tree fndecl,
>{
> base_pointer = TREE_OPERAND (base, 0);
> context->offset
> -+= offset2 + mem_ref_offset (base).low * BITS_PER_U
On Thu, Jan 30, 2014 at 9:42 PM, Bill Schmidt
wrote:
> Hi,
>
> This patch adds logic for -maltivec=be with a little endian target when
> generating code for the vec_sums builtin. This implements the vsumsws
> instruction, which adds the four elements in the first input vector
> operand to element
On Fri, Jan 31, 2014 at 10:28 PM, Jakub Jelinek wrote:
> Without this patch, cprop can propagate e.g. a SYMBOL_REF to former
> (mem (plus (reg) (const_int)))
> making it invalid RTL (as plus of CONSTANT_P arguments must be simplified
> or surrounded by CONST).
But isn't this true for all non-unar
On Fri, Jan 31, 2014 at 6:36 PM, Bill Schmidt
wrote:
> Hi,
>
> One more patch in the set supporting -maltivec=be for the Altivec
> builtins, this one for vec_perm. Most of the work was done already in
> rs6000.c:altivec_expand_vec_perm_le (). We can reuse this logic for the
> present work by gen
The gcc_update file is missing an entry for
gcc/config/aarch64/aarch64.md; this patch adds it.
Ok for trunk?
Thanks,
- Brooks
Index: contrib/ChangeLog
===
--- contrib/ChangeLog (revision 207012)
+++ contrib/ChangeLog (working cop
On January 31, 2014 10:24:22 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As described in the PR, __builtin_setjmp_receiver isn't declared to
>returns_twice, and thus after dce cfun->calls_setjmp might be no longer
>true.
>At RTL __builtin_setjmp_receiver is handled as non-local label, so this
>pat
On February 1, 2014 12:56:45 AM GMT+01:00, Steven Bosscher
wrote:
>On Fri, Jan 31, 2014 at 10:28 PM, Jakub Jelinek wrote:
>
>> Without this patch, cprop can propagate e.g. a SYMBOL_REF to former
>> (mem (plus (reg) (const_int)))
>> making it invalid RTL (as plus of CONSTANT_P arguments must be
>s
On February 1, 2014 12:06:55 AM GMT+01:00, Cong Hou wrote:
>On Fri, Jan 31, 2014 at 5:06 AM, Jakub Jelinek
>wrote:
>>
>> On Fri, Jan 31, 2014 at 09:41:59AM +0100, Richard Biener wrote:
>> > Is that because si and pattern_def_si point to the same stmts?
>Then
>> > I'd prefer to do
>> >
>> > if
On 01/31/14 22:52, Richard Biener wrote:
On February 1, 2014 12:56:45 AM GMT+01:00, Steven Bosscher
wrote:
On Fri, Jan 31, 2014 at 10:28 PM, Jakub Jelinek wrote:
Without this patch, cprop can propagate e.g. a SYMBOL_REF to former
(mem (plus (reg) (const_int)))
making it invalid RTL (as plus
93 matches
Mail list logo
