2014-02-18 7:56 GMT+01:00 Tobias Burnus :
>
> Am 17.02.2014 21:51, schrieb Janus Weil:
>
>> 2014-02-17 21:36 GMT+01:00 Tobias Burnus :
>>>
>>> Janus Weil wrote:
attached is a patch for an ICE-on-invalid problem with generics: We
simply don't check if any dummy args are present.
>>>
>
On Mon, Feb 17, 2014 at 8:34 PM, Jakub Jelinek wrote:
> As discussed in the PR, because -mf16c implies -mavx, if the CPU has
> F16C (and AVX) support, but OS doesn't save YMM state, we shouldn't
> be passing -mf16c.
>
> Also, as noticed by Uros, the clearing of has_fma4 and has_xop if
> OS doesn'
Am 17.02.2014 21:51, schrieb Janus Weil:
2014-02-17 21:36 GMT+01:00 Tobias Burnus :
Janus Weil wrote:
attached is a patch for an ICE-on-invalid problem with generics: We
simply don't check if any dummy args are present.
There is something odd with your test case - and possibly with the patch.
2014-02-17 21:36 GMT+01:00 Tobias Burnus :
> Janus Weil wrote:
>>
>> attached is a patch for an ICE-on-invalid problem with generics: We
>> simply don't check if any dummy args are present.
>
> There is something odd with your test case - and possibly with the patch.
> You state that this is an ICE
> Hi,
>
> On Mon, Feb 17, 2014 at 09:40:40AM +0100, Jan Hubicka wrote:
> > Hi,
> > Chromium LTO build ICEs on bogus get_binfo_at_offset call. This is caused by
> > updating pasto bug in update_jump_functions_after_inlining.
> >
> > While looking for it I noticed we have other issues here. In part
Janus Weil wrote:
attached is a patch for an ICE-on-invalid problem with generics: We
simply don't check if any dummy args are present.
There is something odd with your test case - and possibly with the
patch. You state that this is an ICE-on-invalid problem; however, I do
not see a dg-error
On Mon, Feb 17, 2014 at 05:51:08PM +, Iyer, Balaji V wrote:
> > Regtested/bootstrapped on x86_64-linux, ok for 5.0?
>
> 5.0? you mean 4.9 right?... since this is a minor bug-fix.
No, I meant 5.0, since this isn't a regression. But maybe it could go
even into 4.9. RM's call.
> I would mo
On February 17, 2014 6:03:56 PM GMT+01:00, Nick Clifton
wrote:
>Hi Guys,
>
> There are several tests in the gcc testsuite which implicitly assume a
> 32-bit (or larger) target. The patch below provides fixes for these
> tests in a variety of different ways. Where possible I have tried to
> r
> struct S
> {
>int f0:15;
> - int f1:29;
> + long int f1:29;
> };
IIRC if you change one field here, you need to change both as some
targets won't pack fields together if the types don't match.
Likewise for other struct-field cases.
Hi!
On ARM we ICE on nosanitize-and-inline.c testcase during loop unrolling,
but the bug seems to be on all targets that during expansion the frequency
of the pre-exit basic block is out of bounds.
The problem is that we have a function ending with return 0;, so
that basic block is expanded as un
Hi!
As discussed in the PR, because -mf16c implies -mavx, if the CPU has
F16C (and AVX) support, but OS doesn't save YMM state, we shouldn't
be passing -mf16c.
Also, as noticed by Uros, the clearing of has_fma4 and has_xop if
OS doesn't save YMM state was done before it was set.
Bootstrapped/reg
I have not actively created or reviewed libstdc++ patches for a while.
As committed:
2014-02-17 Loren J. Rittle
* MAINTAINERS (Various Maintainers: c++ runtime libs): Remove myself.
Index: MAINTAINERS
===
--- MAINTAINERS
Hi Marek,
Thanks for working on this. Please see my comments below.
> -Original Message-
> From: Marek Polacek [mailto:pola...@redhat.com]
> Sent: Monday, February 17, 2014 12:43 PM
> To: GCC Patches
> Cc: Iyer, Balaji V
> Subject: [PATCH] Properly check for _Cilk_spawn in return s
I don't know Cilk stuff at all, but it seems that _Cilk_spawn is
forbidden in a return statement. But then only checking
TREE_CODE (retval) == CILK_SPAWN_STMT isn't sufficient, because
CILK_SPAWN_STMT can be wrapped e.g. in MINUS_EXPR, C_MAYBE_CONST_EXPR,
EQ_EXPR, and a bunch of others. I used wa
Hi Guys,
There are several tests in the gcc testsuite which implicitly assume a
32-bit (or larger) target. The patch below provides fixes for these
tests in a variety of different ways. Where possible I have tried to
recode the test so that it will compile on a 16-bit target, but in a
Hi Thomas,
Here is the fix for the issue discussed in
http://gcc.gnu.org/ml/gcc/2014-02/msg00257.html
OK to commit to gomp-4_0-branch?
---
libgomp/ChangeLog.gomp |5 +
libgomp/target.c |5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libgomp/ChangeLog.
The following patch caches the ao_ref (the meta-data used by
the "gimple" alias oracle) in MEM_ATTRs, inheriting the existing
MEM_EXPR and MEM_ALIAS_SET fields. This reduces the load
on the get_ref_base_and_extent and the get_alias_set calls
that are eventually done when rtx_refs_may_alias_p disp
On Mon, Feb 17, 2014 at 04:25:25PM +0100, Richard Biener wrote:
>
> This makes sure pattern stmts do not appear to be in the IL,
> first by setting their BB to NULL again (the vectorizer sets this
> for convenience I guess) and second by releasing SSA names we
> temporarily allocated.
>
> Esp. th
This makes sure pattern stmts do not appear to be in the IL,
first by setting their BB to NULL again (the vectorizer sets this
for convenience I guess) and second by releasing SSA names we
temporarily allocated.
Esp. the non-NULL BB may confuse passes walking over
non-released SSA names.
Bootstr
On Mon, 17 Feb 2014, Jeff Law wrote:
> On 02/17/14 06:42, Richard Biener wrote:
> >
> > This makes us release the virtual SSA name associated with a call that
> > is inlined. This removes some garbage that is otherwise kept live
> > duing early opts (and thus reduces whole-program footprint).
>
On 02/17/14 06:42, Richard Biener wrote:
This makes us release the virtual SSA name associated with a call that
is inlined. This removes some garbage that is otherwise kept live
duing early opts (and thus reduces whole-program footprint).
With this patch and the separately posted ipa-prop chan
Hi all,
attached is a patch for an ICE-on-invalid problem with generics: We
simply don't check if any dummy args are present.
Regtested on x86_64-unknown-linux-gnu. Ok for trunk and 4.8?
Cheers,
Janus
2014-02-17 Janus Weil
PR fortran/60231
* resolve.c (check_generic_tbp_ambiguity):
On Fri, Feb 14, 2014 at 02:15:52PM +, Richard Earnshaw wrote:
> >
> > I've put it in.
> >
> > R.
> >
>
> Kyle, the PR is against 4.8. Have you tested a back-port?
>
Yeah, I've built it against both 4.9 and 4.8... I suspect it'll work
fine for 4.7 too if anyone is still using it.
regards
On 13/02/14 18:23, Richard Henderson wrote:
On 02/03/2014 03:50 AM, Kyrill Tkachov wrote:
+# For ARM, the -march option by itself conflicts with any -mcpu option that
+# we might end up passing to the build, causing an error.
+# Therefore we override the -mcpu option as well.
+# This shouldn't a
Hello All,
I am pinging this documentation patch
http://gcc.gnu.org/ml/gcc-patches/2014-02/msg00074.html
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opini
This adds the missing branch to err.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-02-17 Richard Biener
* tree-ssa.c (verify_ssa): If verify_def found an error, ICE.
Index: gcc/tree-ssa.c
This makes us release the virtual SSA name associated with a call that
is inlined. This removes some garbage that is otherwise kept live
duing early opts (and thus reduces whole-program footprint).
With this patch and the separately posted ipa-prop change I can
bootstrap & regtest with
Index: g
This removes the update_ssa call in ipa_modify_call_arguments by
keeping virtual SSA form up-to-date. It also avoids leaking
the virtual SSA name defined by the replaced call (and thus
keeping more than necessary memory live during early transforms).
Bootstrap and regtest in progress on x86_64-u
On Mon, Feb 17, 2014 at 11:27 AM, Eric Botcazou wrote:
>> There is nothing obvious I think, i.e. that's debatable. I agree that a VCE
>> from a 32-bit object to a 32-bit integer with 24-bit precision should not
>> clear the upper 8 bits (so the REDUCE_BIT_FIELD part of my patch is wrong).
>> But
Hi,
On Mon, Feb 17, 2014 at 09:40:40AM +0100, Jan Hubicka wrote:
> Hi,
> Chromium LTO build ICEs on bogus get_binfo_at_offset call. This is caused by
> updating pasto bug in update_jump_functions_after_inlining.
>
> While looking for it I noticed we have other issues here. In particular, when
> c
> This is OK for trunk, 4.8 and 4.7.
Thanks, Paul. Committed to trunk as r207823. Will do the backports soon.
Cheers,
Janus
> On 16 February 2014 23:11, Janus Weil wrote:
>> Hi all,
>>
>> here is a small patch for a ICE-on-valid regression. Regtested on
>> x86_64-unknown-linux-gnu. Ok for tru
On Mon, Feb 17, 2014 at 1:26 PM, Kirill Yukhin wrote:
>> >> Please don't change srcp pattern, it should be defined similar to
>> >> vrcpss (aka sse_vmrcpv4sf). You need to switch operand order
>> >> elsewhere.
>> >
>> > No, you are correct. Operands should be swapped as in your patch.
>>
>> Eh, s
Hello Uroš,
On 13 Feb 18:25, Uros Bizjak wrote:
> On Thu, Feb 13, 2014 at 1:55 PM, Uros Bizjak wrote:
>
> >>
> >> Please don't change srcp pattern, it should be defined similar to
> >> vrcpss (aka sse_vmrcpv4sf). You need to switch operand order
> >> elsewhere.
> >
> > No, you are correct. Operan
> This adds proper variadic support to the SPARC port of libffi, thus fixing a
> regression in the testsuite in 64-bit mode, and fixes a small inaccuracy in
> the documentation.
Follow-up patch attached. It renames the existing FFI_V9 into FFI_COMPAT_V9
and defines a new FFI_V9 value. In order
Senthil Kumar Selvaraj writes:
> The newly added gcc.dg/torture/pr60183.c test fails for the AVR target
> with an "array size too large" error. This patch marks the test as
> unsupported for AVR, following the example of other such tests in the
> testsuite.
[...]
> diff --git gcc/testsuite/gcc.dg
On Mon, Feb 17, 2014 at 11:13 AM, Eric Botcazou wrote:
> Hi,
>
> this is a regression present on all active branches. The following assertion
> triggers in compute_complex_ancestor_jump_func:
>
> index = ipa_get_param_decl_index (info, SSA_NAME_VAR (parm));
> gcc_assert (index >= 0);
>
> beca
The newly added gcc.dg/torture/pr60183.c test fails for the AVR target
with an "array size too large" error. This patch marks the test as
unsupported for AVR, following the example of other such tests in the
testsuite.
If ok, could someone apply please? I don't have commit access.
Regards
Senthil
Am 16.02.2014 um 16:47 schrieb Mike Stump :
> On Feb 15, 2014, at 9:27 AM, Jonathan Schleifer wrote:
>> The following patch fixes a bug in SEH exception handling that made it
>> crash with ObjC
>
> From an ObjC perspective, I’m fine with the work; though, an seh person needs
> to weigh in. I’m
Dear Janus,
This is OK for trunk, 4.8 and 4.7.
Thanks for the patch.
Paul
On 16 February 2014 23:11, Janus Weil wrote:
> Hi all,
>
> here is a small patch for a ICE-on-valid regression. Regtested on
> x86_64-unknown-linux-gnu. Ok for trunk/4.8/4.7?
>
> Cheers,
> Janus
>
>
> 2014-02-16 Janus W
2014-02-17 Kugan Vivekanandarajah
Index: MAINTAINERS
===
--- MAINTAINERS (revision 207819)
+++ MAINTAINERS (working copy)
@@ -551,6 +551,7 @@
David Ung dav...@mips.com
Neil Vachharajani
> There is nothing obvious I think, i.e. that's debatable. I agree that a VCE
> from a 32-bit object to a 32-bit integer with 24-bit precision should not
> clear the upper 8 bits (so the REDUCE_BIT_FIELD part of my patch is wrong).
> But here we have a VCE from a 24-bit object to a 32-bit integer
Hi,
this is a regression present on all active branches. The following assertion
triggers in compute_complex_ancestor_jump_func:
index = ipa_get_param_decl_index (info, SSA_NAME_VAR (parm));
gcc_assert (index >= 0);
because the PARM_DECL is the static_chain_decl so the returned index is -1
> So, the code has this structure
>
> if (looks safe)
>emit in existing order
> else if (reverse order looks safe)
>emit in reversed order
> else
>undo_all
>
>
> In this specific case, the existing order is never going to look safe
> because set1 uses (sp) as an input argument and us
Hi,
Chromium LTO build ICEs on bogus get_binfo_at_offset call. This is caused by
updating pasto bug in update_jump_functions_after_inlining.
While looking for it I noticed we have other issues here. In particular, when
combining -fno-devirtualize and -fdevirtualize units, we get all jump fuctions
44 matches
Mail list logo
