I'm sending an updated patch (rebased to recent trunk, bootstrapped and
regtested on x86_64-unknown-linux-gnu).
On 04/25/2015 02:49 PM, Richard Sandiford wrote:
> FWIW I think the split between label_rtx and live_label_rtx is good,
> but I think we should give them different names. The first one
On 04/21/2015 11:33 AM, Kyrill Tkachov wrote:
On 21/04/15 15:09, Jeff Law wrote:
On 04/21/2015 02:30 AM, Kyrill Tkachov wrote:
From reading config/stormy16/stormy-abi it seems to me that we don't
pass arguments partially in stormy16, so this code would never be called
there. That leaves pa a
Hi
Can this work be commited to Gcc 6?
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=33cd3712cae4721121bc37aefd09fc5ed7cd146a
The work was posted to the patch liste even before Gcc 5 stage1 ended.
And diffrent versions of it have been posted to the list of nummer of times.
/Magnus G.
On 13/04/15 02:24 +0300, Ville Voutilainen wrote:
The patch is a bit large since it does the baseline_symbols regeneration
and other new-version api-dance.
Hence attached gzipped.
Tested on Linux x86-64.
2015-04-13 Ville Voutilainen
Add support for std::uncaught_exceptions.
* acinclude
Dear Steve,
Thanks for the review. I THINK that I know what I meant in the comment
:-) I will commit tomorrow night.
Cheers
Paul
On 26 April 2015 at 20:53, Steve Kargl
wrote:
> On Sun, Apr 26, 2015 at 08:35:06PM +0200, Paul Richard Thomas wrote:
>>
>> --- 7062,7091
>> {
>>
On 27/04/15 21:40 +0100, Jonathan Wakely wrote:
Tested x86_64-linux and powerpc64le-linux. Committed to trunk.
The baseline_symbols changes aren't needed now and I tweaked the
gnu.ver file slightly.
Ville noticed a typo in a comment I added, fixed like so.
commit c595cfa88c9d38f333b262635a1c32
Jeff Law writes:
> On 04/16/2015 05:04 AM, Jiong Wang wrote:
>>
>> This is a rework of
>>
>>https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01998.html
>>
>> After second thinking, I feel it's better to fix this in earlier stage
>> during RTL expand which is more generic, and we also avoid makin
On 14/04/15 12:17 -0300, Federico Lenarduzzi wrote:
When the libstdc++ is compiled, the compiler sets the std::terminate_handler function
with __verbose_terminate_handler() or std::abort() depending on _GLIBCXX_HOSTED
&& _GLIBCXX_VERBOSE being true or false.
However, even if we compile with -f
On Thu, Apr 23, 2015 at 7:24 AM, Alan Modra wrote:
> Revised patch, supporting linker that aligns the toc base.
>
> This fixes a thinko in offsettable_ok_by_alignment. It's not the
> absolute placement that matters, but the toc-pointer relative offset.
> So alignment of r2 also needs to be taken
Hi.
While we should eventually get the xmethods to handle cxx11,
this patch fixes the current failure.
The xmethod matcher doesn't currently handle __cxx11 in the type name.
Adding cxx11 support can be a follow up patch.
Ok to commit?
2015-04-27 Doug Evans
* testsuite/libstdc++-xmet
On 27 April 2015 at 23:33, Doug Evans wrote:
> Hi.
>
> While we should eventually get the xmethods to handle cxx11,
> this patch fixes the current failure.
> The xmethod matcher doesn't currently handle __cxx11 in the type name.
>
> Adding cxx11 support can be a follow up patch.
Agreed. And when t
Hi.
This patch is the counterpart to this patch to fix
libstdc++/65839, gdb/18285.
https://sourceware.org/ml/gdb-patches/2015-04/msg00947.html
Regression tested on amd64-linux with/without a patched gdb.
Without a patched gdb the new tests fail, but that's good.
2015-04-27 Doug Evans
On Mon, Apr 27, 2015 at 12:30 PM, Jeff Law wrote:
> Looks good to me. Please install if you haven't already done so.
Thanks, I checked in the patch. I'm not maintainer of anything
currently, so I'm assuming all of my patches need to be approved
before check in. I'm pretty rusty, so that is pro
Hi.
This patch adds operator-> support to the unique_ptr xmethod.
Note: This patch assumes these two patches have been committed.
https://sourceware.org/ml/gdb-patches/2015-04/msg00947.html
https://gcc.gnu.org/ml/libstdc++/2015-04/msg00149.html
Regression tested on amd64-linux.
2015-04-27 Doug
I noticed this while working on my mostlyclean patch. The list of
languages in the docs for --enable-languages is incomplete. It is
missing jit and lto. I also noticed that the grep command matches
boot_language= in addition to language= which is a little confusing,
so I added the ^.
The senten
Hi,
actually I bootstrapped/regtested without fortran (as I frogot the setting from
LTO bootstrap). There are several new warnings in the fortran's testsuite.
As far as I can tell, they represent real mismatches. I wonder, do we want
to fix the testcases (some fortran-fu would be needed), disable
This patch works around a libstdc++ testsuite issue: the generated
program that tests for the availability of named locales dereferences
invalid pointers on targets that don't allow command-line arguments to
be passed. (In particular, I ran into this with a simulator for an
embedded target th
Richi recently changed tree-ssa-dom.c::record_equality to use
tree_swap_operands_p to canonicalize the implied copy we record for
equality comparisons. This is a good thing.
However, there is a case where tree_swap_operands_p gives us operands in
an undesirable order for this routine. Spec
On Mon, Apr 27, 2015 at 4:57 AM, Jonathan Wakely wrote:
> OK for trunk.
Committed.
--
Regards,
Tim Shen
Hi all,
Jan Hubicka wrote:
actually I bootstrapped/regtested without fortran (as I frogot the setting from
LTO bootstrap). There are several new warnings in the fortran's testsuite.
As far as I can tell, they represent real mismatches. I wonder, do we want
to fix the testcases (some fortran-fu
Hi,
this patch adds bare bones of type checker. You can call verify_type on any
type in the IL and see compiler bomb if some of invariants are broken. So far
it only verify tests I already tested in last stage1 with my reverted variant
streaming patch https://gcc.gnu.org/ml/gcc-patches/2014-06/ms
101 - 121 of 121 matches
Mail list logo
