On Aug 25, 2013, at 8:32 PM, Alan Modra wrote:
> We (IBM) don't intend to support running both big and little-endian
> processes on the same system in the near future. Perhaps I'm jumping
> the gun in defining the multi-os dirs like /lible and /lib64le.
I'd recommend against multilibs, unless yo
On 08/25/2013 06:55 PM, Mike Stump wrote:
On Aug 25, 2013, at 12:26 AM, Richard Sandiford
wrote:
(2) Adding a new namespace, wi, for the operators. So far this
just contains the previously-static comparison functions
and whatever else was needed to avoid cross-dependencies
between
On Fri, Aug 23, 2013 at 10:08:29PM +, Joseph S. Myers wrote:
> On Fri, 23 Aug 2013, Alan Modra wrote:
>
> > I'd like to import upstream libtool into gcc to support powerpc64le,
>
> Has the sysroot semantics issue been resolved in upstream libtool, or do
> you mean "import with 3334f7ed5851ef
On Fri, Aug 23, 2013 at 09:41:28PM +, Joseph S. Myers wrote:
> On Thu, 22 Aug 2013, Alan Modra wrote:
>
> > For multiarch, powerpc64le-linux now will use powerpc64le-linux-gnu.
> > Given a typical big-endian native toolchain with os dirs /lib and
> > /lib64, we'll use /lible and /lib64le if su
Same topic as patch 15/n, but postfix_expression.
Tested on an x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-25 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::postfix_expression): Now a
virtual member function.
(pp_postfix_expression): Ad
OK.
Jason
On Aug 25, 2013, at 12:26 AM, Richard Sandiford
wrote:
> (2) Adding a new namespace, wi, for the operators. So far this
>just contains the previously-static comparison functions
>and whatever else was needed to avoid cross-dependencies
>between wi and wide_int_ro (except for the debu
Hi,
My earlier patch that formally desclared pretty_printer as polymorphic
uncovered a latent bug in the existing build machinery of the Ada
component. It had been using xgcc to link against C++ source files. It
should use xg++ instead.
This patch fixes that by introducing GXX_LINK which is GC
Shorten some wording. Avoid direct references to Bugzilla and CVS.
Move a comment to where it belongs (the subscription form).
Installed.
Gerald
Index: lists.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/lists.html,v
retrieving revisi
On Aug 25, 2013, at 1:11 PM, "Joseph S. Myers" wrote:
> On Sun, 25 Aug 2013, Mike Stump wrote:
>> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
>> wrote:
>>> We really need to get rid of the #include "tm.h" in wide-int.h.
>>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependen
On Sun, 25 Aug 2013, Mike Stump wrote:
> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
> wrote:
> > We really need to get rid of the #include "tm.h" in wide-int.h.
> > MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
> > thing in there. If that comes from tm.h then perhap
On Aug 25, 2013, at 11:29 AM, Richard Sandiford
wrote:
> Looks like wide-int is just using BITS_PER_UNIT to get the number of
> bits in "char". That's a host thing, so it should be CHAR_BIT instead.
Oh, Kenny did point out one sin:
diff --git a/gcc/wide-int.cc b/gcc/wide-int.cc
index 37ce5b3..
On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
> | Previously, each string was inside a separate call to M_() - the strings
> | themselves were the msgid parameters. Now, the msgid parameter is not a
> | single string but a more complicated expression and xgettext may not
> | handle such express
On Aug 25, 2013, at 11:29 AM, Richard Sandiford
wrote:
> Mike Stump writes:
>> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
>> wrote:
>>> We really need to get rid of the #include "tm.h" in wide-int.h.
>>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
>>> thing in the
On Tue, 20 Aug 2013, Florian Weimer wrote:
> As the libvtv reviewer, you don't need permission to commit your
> changes. :-)
Actually, reviewers do need someone else's approval for their own
changes (unlike maintainers and of course not for trivial changes).
Not a biggie in this case, just wante
cleaned up code to get around tree-vrp issue. added some code that
richard is going to play with to see how hard it would be to clean up
rtl constants.
kenny
Index: gcc/wide-int.cc
===
--- gcc/wide-int.cc (revision 201968)
+++ gc
Mike Stump writes:
> On Aug 23, 2013, at 8:02 AM, Richard Sandiford
> wrote:
>> We really need to get rid of the #include "tm.h" in wide-int.h.
>> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
>> thing in there. If that comes from tm.h then perhaps we should put it
>> in
Same topic as patch 14/n. This time for primary_expression.
-- Gaby
2013-08-25 Gabriel Dos Reis
c-family/
* c-pretty-print.h (c_pretty_printer::primary_expression): Now a
virtua member function.
(pp_primary_expression): Adjust.
(pp_c_primary_expression): Rem
"Joseph S. Myers" writes:
[...]
| > | > @@ -379,15 +375,15 @@
| > | > switch (code)
| > | > {
| > | > case INTEGER_TYPE:
| > | > - pp_string (pp, (TYPE_UNSIGNED (t)
| > | > - ? M_(" | > -
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
> We really need to get rid of the #include "tm.h" in wide-int.h.
> MAX_BITSIZE_MODE_ANY_INT should be the only partially-target-dependent
> thing in there. If that comes from tm.h then perhaps we should put it
> into a new header file instea
On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
> I don't know whether after the switch C++ xgettext is being invoked
> explicitly with -C or --c++, or whether we are still relying on xgettext
> to pick the language based on the file extension. This is probably
> another reason why we might want to
Le 22/08/2013 23:30, Mikael Morin a écrit :
> Le 14/08/2013 23:46, Thomas Koenig a écrit :
>> Hello world,
>>
>> the attached patch enables more sophisticated bounds-checking on
>> array slices by using gfc_dep_difference to calculate extents.
>> The information may also be useful in other places o
> Naming suggestion: we already use cpp_ as prefix for the C preprocessor.
> Could we please not use it for C++, given that tree is used by so
> many clients for just about anything. cxx_ is a good alternative.
CXX is fine with me. I updated by local copy.
Honza
>
> > unsigned final : 1;
>
On Sun, Aug 25, 2013 at 10:38 AM, Jan Hubicka wrote:
>> On 08/24/2013 05:18 AM, Jan Hubicka wrote:
>> >In the next step I would like to introduce the
>> >DECL_CPP_CONSTRUCTOR/DESTRUCTOR macro.
>> >The catch I run into is that these flags are tested on TEMPLATE_DECL so the
>> >middle-end
>> >macr
> On 08/24/2013 05:18 AM, Jan Hubicka wrote:
> >In the next step I would like to introduce the
> >DECL_CPP_CONSTRUCTOR/DESTRUCTOR macro.
> >The catch I run into is that these flags are tested on TEMPLATE_DECL so the
> >middle-end
> >macro bombs on type checking. I wonder what is best approach he
"Joseph S. Myers" writes:
| On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
|
| > Instead of defining the same macro several times in different
| > translation units, we can just make it a function and use it where
| > needed.
|
| Have you made sure that po/exgettext still extracts the relevant me
Hi, GCC global reviewers,
The nds32 port initial patch is still awaiting for
any global reviewer's approval.
Since there is no further comment in these days,
is it OK for trunk?
Thanks in advance. :)
Best regards,
jasonwucj
2013/8/13 Chung-Ju Wu :
> Hi, GCC Global Maintainers,
>
> The Andes
Hi,
this patch adds code to stream DECL_FINAL_P/TYPE_FINAL_P into LTO so we can
use it after the ipa-devirt code at LTO time is merged in.
(http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01007.html)
Bootstrapped/regtested x86_64-linux, OK?
Honza
* lto-streamer-out.c (hash_tree): Add stream
Hi,
this patch adds ipa-devirt code for final types and methods. There is
probably no way to construct a testcase that will be devirtualized,
since all the simple minded devirtualization is already done by FE.
I however checked that dumps seems sane at least. Once we are able
to track types of TH
On Sun, 25 Aug 2013, Gabriel Dos Reis wrote:
> Instead of defining the same macro several times in different
> translation units, we can just make it a function and use it where
> needed.
Have you made sure that po/exgettext still extracts the relevant messages
for translation (I'm not sure how
On 08/25/2013 02:42 AM, Richard Sandiford wrote:
Kenneth Zadeck writes:
On 08/24/2013 08:05 AM, Richard Sandiford wrote:
Richard Sandiford writes:
I wonder how easy it would be to restrict this use of "zero precision"
(i.e. flexible precision) to those where primitive types like "int" are
us
Hi,
this bug, filed by Diego, is about 8.3.6/6, where member functions of
class templates, at variance with plain classes, do not admit default
arguments on the out-of-class redeclaration.
Tested x86_64-linux.
Thanks,
Paolo.
//
/cp
2013-08-25 Paolo Carlini
32 matches
Mail list logo
