On Tue, Mar 17, 2015 at 11:27 AM, Jeff Law wrote:
> On 03/17/2015 04:35 AM, Richard Biener wrote:
>
>>> I'll test both. In the common case, the cost is going to be the basic
>>> bookkeeping so that we can compute the transparent property. The
>>> actual
>>> computation of transparency and everyt
On Tue, Mar 17, 2015 at 01:28:41PM -0600, Jeff Law wrote:
> On 03/14/2015 07:02 AM, Alan Modra wrote:
> > PR target/65408
> > PR target/58744
> > PR middle-end/36043
> > * calls.c (load_register_parameters): Don't load past end of
> > mem unless suitably aligned.
> I think this
On 03/17/2015 10:03 PM, Paolo Carlini wrote:
Hi,
On 03/18/2015 01:11 AM, Jason Merrill wrote:
On 03/17/2015 01:09 PM, Paolo Carlini wrote:
- require_deduced_type (decl);
+ if (complain & tf_error)
+require_deduced_type (decl);
I think we want to return false if there's a problem here s
On 03/17/2015 03:58 PM, Aldy Hernandez wrote:
The problem is that, for -fno-implicit-templates, the decl is now
DECL_EXTERNAL, which means we never equate this new "DIE with
DW_AT_specification" to the DECL. That is, we never fall through here:
else if (!DECL_EXTERNAL (decl))
{
H
Hi,
On 03/18/2015 01:11 AM, Jason Merrill wrote:
On 03/17/2015 01:09 PM, Paolo Carlini wrote:
- require_deduced_type (decl);
+ if (complain & tf_error)
+require_deduced_type (decl);
I think we want to return false if there's a problem here so that we
don't just silently accept this in
On 03/17/2015 01:09 PM, Paolo Carlini wrote:
- require_deduced_type (decl);
+ if (complain & tf_error)
+require_deduced_type (decl);
I think we want to return false if there's a problem here so that we
don't just silently accept this in SFINAE context. So probably we want
to replace th
On Mon, Mar 16, 2015 at 8:01 PM, H.J. Lu wrote:
> On Mon, Mar 16, 2015 at 7:26 PM, H.J. Lu wrote:
>> On Mon, Mar 16, 2015 at 4:43 PM, H.J. Lu wrote:
>>> On Mon, Mar 16, 2015 at 4:41 PM, Joseph Myers
>>> wrote:
On Mon, 16 Mar 2015, H.J. Lu wrote:
> On Mon, Mar 16, 2015 at 3:50 PM,
Twiddle the assert. A DW_TAG_type_unit in limbo can happen under normal
circumstances while breaking out comdat types.
Found while running the gdb testsuite.
Committed to branch.
Aldy
commit 1c2137a25b7ffa2ab71fe4d534ab149624c5c841
Author: Aldy Hernandez
Date: Tue Mar 17 16:50:14 2015 -070
Hi Martin,
Sorry for the late answer...
On Sun, Mar 15, 2015 at 05:39:59PM -0600, Martin Sebor wrote:
> I tested the changes in powerpc64*-linux-* native builds and on
> an x86_64 host in a build for the powerpc-unknown-linux-gnu and
> powerpc64-apple-darwin targets. Of these, the -mprofile-kerne
I have checked in this change. Validated as XHTML 1.0 Transitional.
Jim
Index: htdocs/steering.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/steering.html,v
retrieving revision 1.39
diff -r1.39 steering.html
41c41
< Jim Wilson (Cisco)
-
Oh bother! Thanks Jakub - I did wonder about that but thought that the
same function would yield the same result :-(
Thanks. I will put it right.
Paul
On 17 March 2015 at 18:32, Jakub Jelinek wrote:
> On Tue, Mar 17, 2015 at 06:28:03AM +0100, Paul Richard Thomas wrote:
>> Dear Tobias,
>>
>> As
On Tue, Mar 17, 2015 at 01:32:20PM -0600, Jeff Law wrote:
> My inclination is to defer unless it's painfully safe (like your removal of
> unused functions) or it's a regression of some sorts.
I think I also slightly prefer deferring this patch; it's not exactly in the
"painfully safe" category.
Hi Jason.
I merged mainline into the debug-early branch and I ran into a problem
compiling a libstdc++ file with -fno-implicit-templates. The attached
patch is what I used to solve the problem but I wanted to run it by you,
to make sure I'm not overlooking something silly, or worse...somethin
On 03/12/2015 07:20 AM, Richard Biener wrote:
After noticing tree-parloop.c passing crap to split_block (a tree
rather than a gimple or an rtx) I noticed those CFG functions simply
take void * pointers. The following patch fixes that and adds
two overloads, one for GIMPLE use and one for RTL us
On 03/12/2015 11:37 AM, Marek Polacek wrote:
The PR shows that the compiler ICEs whenever it tries to expand an atomic
operation at the file scope. That happens because it creates temporaries
via create_tmp_var, which also pushes the variable into the current binding,
but that can't work if curr
On 03/14/2015 07:02 AM, Alan Modra wrote:
This is Richi's prototype patch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043#c23 with fixes for
blocks larger than one reg, big-endian, and BLOCK_REG_PADDING.
I also removed the operand_subword_force since we may as well let
narrow_bit_field_mem
On 03/15/2015 02:30 PM, Richard Sandiford wrote:
Ilya Enkovich writes:
This patch allows propagation of loop invariants for i386 if propagated
value is a constant to be used in address operand. Bootstrapped and
tested on x86_64-unknown-linux-gnu. OK for trunk or stage 1?
Is it necessary for
On 03/16/2015 04:12 AM, Kyrill Tkachov wrote:
Hi all,
Eyeballing the mult_by_coeff_cost function I think it has a typo/bug.
It's supposed to return the cost of multiplying by a constant 'coeff'.
It calculates that by taking the cost of a MULT rtx by that constant
and comparing it to the cost of
On 03/17/2015 02:17 AM, Andreas Krebbel wrote:
Just to have some numbers I did run a -j1 GCC bootstrap twice with and without
the patch on x86_64.
Best results for both are:
clean: 21459s
patched: 21314s
There rather appears to be a trend towards reduced compile time perhaps due to
the red
On 03/17/2015 04:35 AM, Richard Biener wrote:
I'll test both. In the common case, the cost is going to be the basic
bookkeeping so that we can compute the transparent property. The
actual
computation of transparency and everything else is guarded on having
something in the hash tables -- and t
On Tue, Mar 17, 2015 at 7:36 AM, wrote:
> I have a patch to get gccgo to work on cross.
>
> Is it too late to try and get this into gcc 5.0?
I think it's still possible. Depends on how small and safe it is.
Ian
> On Tuesday, February 3, 2015 at 2:18:39 PM UTC-6, Ian Lance Taylor wrote:
>>
>>
Hi!
This patch fixes a regression where since the removal of specialized
builtin from _mm_storel_epi64 we force the extraction of DImode (or SImode)
low value out of 16/32/64 byte vector registers into memory.
As the vector extraction is from a vector register with a different
element mode, the ex
By the time we get to the lower have of cp_parser_template_name, we
don't need to keep the USING_DECL around, we can strip it away and just
deal with the underlying template.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0c6a93e343cbd6ce5c5c341b65eca721b58dae46
Author: Jason Merrill
Da
On Tue, Mar 17, 2015 at 06:28:03AM +0100, Paul Richard Thomas wrote:
> Dear Tobias,
>
> As far as I can see, without the patch, gfc_get _derived_type goes
> into a continuous loop trying to build the abstract type. Why this is
> not the case with an additional non-procedure pointer component, I do
Hi,
this minor [5 Regression], an ICE on invalid, seems just matter of
passing the tsubst_flags_t argument from build_over_call to mark_used
and then guarding require_deduced_type in the latter. Tested x86_64-linux.
Thanks,
Paolo.
/
2015-03-17 Paolo Carlini
I noticed that testsuite/30_threads/shared_lock/modifiers/2.cc is
almost identical to 1.cc in the same directory, except for the diff
shown in the attached patch. That file was copied from
testsuite/30_threads/unique_lock/modifiers/2.cc which is almost
identical to 1.cc in that directory.
So I'm
On 02/03/15 18:43, Aldy Hernandez wrote:
TYPE_BINFO is null when no optimization is used, but odr_violated is unset.
Fixed and approved in the PR by Honza.
Tested on x86-64 Linux.
Committed to mainline.
Hi,
I believe your testcase does not work for arm-none-eabi:
Executing on host: /arm-no
Stephan Lavavej pointed out some flaws in our std::nested_exception,
most of which I fixed with the recent rewrite for GCC 5, but I didn't
check for final classes.
Tested x86_64-linux, committed to trunk.
commit 7202d181bc2aa72432ef472ace1a37bc841b51c5
Author: Jonathan Wakely
Date: Mon Mar 16
2015-03-17 13:36 GMT+01:00 Jason Merrill :
> On 03/16/2015 03:22 PM, Kai Tietz wrote:
>>
>> 2015-03-16 19:07 GMT+01:00 Jason Merrill :
>>>
>>> If there is an alignment mismatch without user intervention, there is a
>>> problem, we can't just ignore it.
>>>
>>> Where we run into trouble is with arra
On 03/16/2015 03:22 PM, Kai Tietz wrote:
2015-03-16 19:07 GMT+01:00 Jason Merrill :
If there is an alignment mismatch without user intervention, there is a
problem, we can't just ignore it.
Where we run into trouble is with array types where the version built
earlier has not been laid out yet b
> What do you think of the attached patch ? Is it suitable for submission
> once the sources are out of stage 4 ? (No regressions with an
> x86_64-pc-linux-gnu toolchain and several fixes for an rl78-elf toolchain).
Yes, I think it's appropriate for the next stage 1, bearing in mind that there
On March 16, 2015 8:45:18 PM GMT+01:00, Jeff Law wrote:
>On 03/16/15 13:27, Jakub Jelinek wrote:
>> On Wed, Mar 11, 2015 at 03:30:36PM -0600, Jeff Law wrote:
>>> +#ifndef GCC_GCSE__COMMONH
>>> +#define GCC_GCSE__COMMONH
>>
>> GCC_GCSE_COMMON_H instead?
>:-) Will fix.
>
>>
>>> @@ -1308,8 +1396,19 @
Dear Andre,
I have bootstrapped and regtested successfully r221474 with your set of
patches. I am seeing some more fixes, but also some new ICEs and segfaults
(some of them being regressions):
(1) The patches fix pr63230.
(2) The test in pr51550 compiles, but segfaults at run time.
(3) The origi
On 03/10/2015 11:27 AM, Richard Biener wrote:
> On Tue, Mar 10, 2015 at 10:19 AM, Andreas Krebbel
> wrote:
>> On 03/10/2015 10:12 AM, Steven Bosscher wrote:
>>> On Tue, Mar 10, 2015 at 8:57 AM, Andreas Krebbel wrote:
* gcc/ifcvt.c (if_convert):
>>>
>>> ...yes...?
>>
>> Damn.
34 matches
Mail list logo
