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*
+000
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.
Bootstrap+testsu
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
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 fro
Hi,
tested x86_64-linux.
Thanks,
Paolo.
/
2014-04-13 Paolo Carlini
* pt.c (mark_template_parm): Use template_parm_level_and_index.
Index: pt.c
===
--- pt.c(revision 209339)
+++ pt.c(w
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 testsu
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 an
On Mon, 3 Mar 2014, Richard Biener wrote:
On Sat, Mar 1, 2014 at 3:33 PM, Marc Glisse 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 write a strictly valid
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
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 s
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 p
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 b
On Sun, Apr 13, 2014 at 09:24:28PM -0400, Hans-Peter Nilsson wrote:
> 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) configurati
Jakub Jelinek writes:
>> I just noticed that I see this error, so the problem still
>> exists at r209347 (seen for cris-elf).
>>
>> (The FAILs are old and provided only for context; the ERRORs are
>> fatal.)
>
> Does say following patch make the problem go away?
>
> --- gcc/gcc/testsuite/g++.dg/
> At the last C++ meeting I got the committee to accept wording that
> ought to allow us to set DECL_IS_MALLOC on the built-in operator
> new:
>
> Furthermore, for the library allocation functions in 18.6.1.1
> [new.delete.single] and 18.6.1.2 [new.delete.array], p0 shall point
> to a block of sto
23 matches
Mail list logo
