Hello,
this patch generates typeinfo for target types. On x86_64, it adds these 6
lines to nm -C libsupc++.a. A follow-up patch will be needed to export and
version those in the shared library.
+ V typeinfo for __float128
+ V typeinfo for __float128 const*
No, it does seem deleted, I can't find it. I can only find its
deletion in the patch, not any re-insert or rewrite and I can't
find this information in the web-pages at limegreensocks. To
wit: where's the corresponding information; the replacement for
the section which started with Sometimes
Hello,
some people like having a macro to test if a type is available
(__SIZEOF_INT128__ for instance). This adds macros for __float80 and
__float128. The types seem to be always available, so I didn't add any
condition.
If you think this is a bad idea, please close the PR.
On Thu, 10 Apr 2014, Tobias Burnus wrote:
I would like to ping the patch:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01673.html
It's a syntax issue: It simply makes no sense to have a @menu item
which points to @nodes which are at the same or higher level
than the section in which the
On Fri, 11 Apr 2014, Yufeng Zhang wrote:
Ping~
Originally posted here:
http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01282.html
Looks okay to me, that I'd prefer it to be approved by a target
maintainer -- AArch64 here.
Gerald
This PR is about spurious warnings with -Wmissing-field-initializers
that can be seen when using multi-level designated initializers.
The warning should not be output for designated initializers [*],
pop_init_level checks for constructor_designated. But push_init_level
clears this variable, so we
Gerald Pfeifer wrote:
Looks fine to me. And probably a good idea for the 4.9 branch as well.
Thanks for the review! However, Jakub has already approved and committed
it for me, just before he has branched 4.9 :-)
Tobias
Hi,
this is a small clean-up discussed some time ago with Jason. The basic
idea seems pretty straightforward to me. However, at variance with that
discussion, I'm not proposing replacing the C++ front-end
TYPE_IDENTIFIER with the new TYPE_NAME_IDENTIFIER because, as far as I
can see, that
Hi,
tested x86_64-linux.
Thanks,
Paolo.
/
2014-04-13 Paolo Carlini paolo.carl...@oracle.com
* pt.c (mark_template_parm): Use template_parm_level_and_index.
Index: pt.c
===
--- pt.c(revision
Ping! This is PR52539
On 03/29/2014 09:58 PM, Jerry DeLisle wrote:
Hi all,
The attached patch fixes namelist read/write and list directed read/write to
support UTF-8.
I have attached a preliminary test case to use to experiment with this. I
will
need to set it up for the testsuite
Hi all,
the attached and committed (Rev. 209348) patch fixes two issues and
prepares for pulling (getting) data from remote hosts by inserting an
intrinsic function (inaccessible from the outside) when a coindexed
expression is used. The code is a bit eager as it also adds it to the
LHS of
On Mon, 3 Mar 2014, Richard Biener wrote:
On Sat, Mar 1, 2014 at 3:33 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
again, a stage 1 patch that I will ping then, but early comments are
welcome.
PR 59100 was asking to transform n?rotate(x,n):x to rotate(x,n) (because it
can be hard to
On Sun, 13 Apr 2014, dw wrote:
So, how about this:
1) I put the (rephrased) text and examples at the end of Local Reg Vars page
(starts with Sometimes):
http://www.LimeGreenSocks.com/gcc/Local-Reg-Vars.html
2) In the constraint paragraph for both Input and Output, I added this: If
you must
On Fri, 11 Apr 2014, Jakub Jelinek wrote:
On Thu, Apr 10, 2014 at 02:18:26PM +0100, Ramana Radhakrishnan wrote:
I see failures from last night on aarch64-none-elf and arm-none-eabi
(both bare-metal) configurations even after moving up to dejagnu
1.5.1. If this can't be fixed easily should
Hi,
GCC changes(http://gcc.gnu.org/gcc-4.9/changes.html) says:
AddressSanitizer, a fast memory error detector, is now available on
ARM.
But I test it,and find PR60281 is still there!That means the wrong
shadow bytes will still populate using stm instructions.
So,I don't
On 04/11/2014 03:08 PM, Zamyatin, Igor wrote:
I remembered - I haven't used cp_parser_require since it calls
cp_lexer_consume_token which is not needed at this point. It is already called
a bit earlier.
So the call to cp_parser_require can replace that call as well.
Jason
OK.
Jason
On 04/13/2014 04:41 AM, Marc Glisse wrote:
this patch generates typeinfo for target types. On x86_64, it adds these
6 lines to nm -C libsupc++.a. A follow-up patch will be needed to export
and version those in the shared library.
This looks fine, but shouldn't be checked in without that other
On 04/13/2014 09:24 PM, Hans-Peter Nilsson wrote:
Can this please be reverted and a patch circulated for testing
instead?
Done, sorry.
Jason
On 04/13/2014 12:20 PM, Paolo Carlini wrote:
this is a small clean-up discussed some time ago with Jason. The basic
idea seems pretty straightforward to me. However, at variance with that
discussion, I'm not proposing replacing the C++ front-end
TYPE_IDENTIFIER with the new TYPE_NAME_IDENTIFIER
20 matches
Mail list logo
