Dear All,
I try to develop a gcc based compiler (I am beginner to gcc) for very simple m
assively parallel processing (MPP) system.
So, I consider the RTL to MD part in now.
Anyone know a site about introduction to the part (focusing to the MPP), excep
ting for gcc internal site.
I want to devel
Hi,
On Mon, 2 Jul 2012, Jeff Law wrote:
> On 07/02/2012 11:53 AM, Paolo Carlini wrote:
> >
> > I also want to mention (I don't think somebody did already in the
> > thread) that at some point, with Jason too, we discussed the idea of
> > adding to each binary a marker about the ABI version which
There seem to be two areas of concern with compatibility between the
C++98 and C++11 ABIs:
1) Changes to member function return types, as with std::complex. For
these, the two functions could coexist except that they are mangled the
same way. So I propose that we introduce a mechanism to cha
On 07/03/2012 08:08 AM, Michael Matz wrote:
Hi,
On Mon, 2 Jul 2012, Jeff Law wrote:
On 07/02/2012 11:53 AM, Paolo Carlini wrote:
I also want to mention (I don't think somebody did already in the
thread) that at some point, with Jason too, we discussed the idea of
adding to each binary a mark
On 06/18/2012 04:46 AM, Jonathan Wakely wrote:
The problems arise when user code that uses the "inline-only" code is
linked to other user-code that has a different definition of that
inline-only code.
What problems arise then? As long as the interface of the user code is
the same, it doesn't
On 3 July 2012 20:36, Jason Merrill wrote:
> On 06/18/2012 04:46 AM, Jonathan Wakely wrote:
>>
>> The problems arise when user code that uses the "inline-only" code is
>> linked to other user-code that has a different definition of that
>> inline-only code.
>
>
> What problems arise then? As long
Hi,
On 07/03/2012 09:18 PM, Jason Merrill wrote:
2) Object layout changes to std::list and std::basic_string. For
these types, there is no way to both retain backward compatibility
with older C++98 code and conform to the C++11 standard. The best we
can hope for is to allow old code to coexi
2012/7/3 Paolo Carlini :
> Hi,
>
> On 07/03/2012 09:18 PM, Jason Merrill wrote:
>>
>> 2) Object layout changes to std::list and std::basic_string. For these
>> types, there is no way to both retain backward compatibility with older
>> C++98 code and conform to the C++11 standard. The best we can
On 07/03/2012 10:10 PM, Daniel Krügler wrote:
Isn't there a similar problem with the long long related additions of
virtual function to IO/localization as in std::num_get and std::num_put?
Probably not, because, if I understand correctly what you are saying, we
have long long overloads in C++98
2012/7/3 Paolo Carlini :
> On 07/03/2012 10:10 PM, Daniel Krügler wrote:
>>
>> Isn't there a similar problem with the long long related additions of
>> virtual function to IO/localization as in std::num_get and std::num_put?
>
> Probably not, because, if I understand correctly what you are saying,
On 07/03/2012 03:59 PM, Jonathan Wakely wrote:
Returning a std::pair by value from a function causes problems if the
caller and callee don't use the same -std setting,
http://gcc.gnu.org/PR53657 and three or four other PRs.
Right, that's because the changes to pair changed its interface. This
On 07/03/2012 04:02 PM, Paolo Carlini wrote:
Just wanted to mention / record the case of std::time_get which has an
additional virtual function (do_get) in C++11. I don't think it affects
in important ways the points you are making.
As long as the new virtual function is at the end, it would on
On 07/03/2012 03:18 PM, Jason Merrill wrote:
It seems that ELF symbol versioning could be useful for this purpose. If
we were to extend the visibility attribute to also handle symbol
versions, that could handle a lot of issues. If Wrap uses the GLIBCXX_4
version of string, then Wrap would also be
On Tue, Jul 3, 2012 at 1:02 PM, Paolo Carlini wrote:
> Hi,
>
>
> On 07/03/2012 09:18 PM, Jason Merrill wrote:
>>
>> 2) Object layout changes to std::list and std::basic_string. For these
>> types, there is no way to both retain backward compatibility with older
>> C++98 code and conform to the C+
Hello,
Since r188786, expmed.c has this code:
bool is_neg;
(...)
if (CONST_INT_P (scalar_op1))
{
coeff = INTVAL (scalar_op1);
is_neg = coeff < 0;
}
else if (CONST_DOUBLE_P (scalar_op1))
{
if (CONST_DOUBLE_HIGH (scalar_op1) ==
GNU MPFR 3.1.1 ("canard à l'orange", patch level 1) is now available
for download from the MPFR web site:
http://www.mpfr.org/mpfr-3.1.1/
from INRIAGForge:
https://gforge.inria.fr/projects/mpfr/
and from the GNU FTP site:
http://ftp.gnu.org/gnu/mpfr/
Thanks very much to those who sent u
On Tue, Jul 03, 2012 at 05:01:29PM -0400, Jason Merrill wrote:
> On 07/03/2012 03:18 PM, Jason Merrill wrote:
> >It seems that ELF symbol versioning could be useful for this purpose. If
> >we were to extend the visibility attribute to also handle symbol
> >versions, that could handle a lot of issue
17 matches
Mail list logo
