CC: gcc@gcc.gnu.org.
On 13/03/2012, at 1:48 PM, peng zhao wrote:
> Hi, Maxim,
>
>Thanks a lot for the help.
>
> Why are they called BEGIN_DATA and BE_IN_DATA? I was trying to find out
> what the names stand for but failed. what do "BE" and "IN" mean in BE_IN_DATA?
BE IN DATA specula
So, I've got something put together. I think it should be fairly scalable.
As a test I've thrown in some ARM overrides.
See
git://repo.or.cz/gcc/rth.git rth/libatomic
which is a gcc tree with a libatomic subdir.
Comments welcome. Andrew, didn't you say you had some code as well, but
didn't
I gave a talk at PyCon 2012 on Friday about my Python plugin for GCC,
how this lowers the barrier for entry to potential GCC hackers, and how
I've been using this to find reference-counting errors in 3rd-party
Python C extensions.
A video of the talk can be seen here:
http://pyvideo.org/video/648/
Hello,
I'm trying to port a private backend from GCC 4.5 to 4.7, and I'm seeing
some performance degradation in HImode benchmarks. The backend has no
HImode insns apart from the mov and SImode extensions.
I tracked one of the regressions down to the RTL expansion pass. The 4.7
version won't gene
On Tue, 13 Mar 2012, paul.chav...@fnac.net wrote:
> It seems that gcc/libstdc++-v3/acinclude.m4 doesn't check for bugs in
> early glibc-2.2.x series anymore. So, it doesn't detect the lack of
> newlocale, duplocale, freelocale, nl_langinfo_l and uselocale. On the
> other hand, there is a new te
On Tue, Mar 13, 2012 at 6:43 AM, Jonathan Wakely wrote:
>> This should have been CC'd to the libstdc++ list too.
>>
>>> C++ programs don't link anymore with gcc > 4.5.3 and eglibc 2.15 with
>>> OPTION_EGLIBC_LOCALE_CODE=n.
>>>
>>> It seems that gcc/libstdc++-v3/acinclude.m4 doesn't check for bugs
gcc.gnu.org bounced the previous email for some reason...
On 03/12/2012 06:51 PM, Joe Gottman wrote:
On 3/12/2012 8:44 AM, Andrew MacLeod wrote:
On 03/10/2012 09:17 AM, Joe Gottman wrote:
According to the news on the front page, the C++11 memory model
has been added to gcc. But C++11 stat
The GCC 4.4 branch is no longer officially maintained, GCC 4.4.7 has been
the last release from the branch. The GCC 4.4 branch is now closed,
please do not apply any changes to the 4.4 branch from now on.
The GNU Compiler Collection version 4.4.7 has been released.
GCC 4.4.7 is a bug-fix release containing fixes for regressions and serious
bugs in GCC 4.4.6. This release marks the end of the maintainance of
the GCC 4.4 series.
This release is available from the FTP servers listed at:
http://www
On 13 March 2012 09:37, Jonathan Wakely wrote:
> On 13 March 2012 07:41, wrote:
>> Hello.
>
> This should have been CC'd to the libstdc++ list too.
>
>> C++ programs don't link anymore with gcc > 4.5.3 and eglibc 2.15 with
>> OPTION_EGLIBC_LOCALE_CODE=n.
>>
>> It seems that gcc/libstdc++-v3/acin
Hi,
I'm trying to make some peephole2 optimizations working (gcc 4.6.1), but
it seems the REG_DEAD information is lost during or after reload.
In the following peephole2 definition, peep2_reg_dead_p returns false,
whereas REG_DEAD information is correctly set before reload for
operands[0] on the
On 13 March 2012 07:41, wrote:
> Hello.
This should have been CC'd to the libstdc++ list too.
> C++ programs don't link anymore with gcc > 4.5.3 and eglibc 2.15 with
> OPTION_EGLIBC_LOCALE_CODE=n.
>
> It seems that gcc/libstdc++-v3/acinclude.m4 doesn't check for bugs in early
> glibc-2.2.x se
niXman a écrit:
> Hi,
Hello niXman,
> Can you please tell, auto is implemented based on the decltype
> implementation with some semantics, or they are two completely
> different implementations?
I think they are different.
> And one more question: in which files/functions I can view the
> imp
Hello.
C++ programs don't link anymore with gcc > 4.5.3 and eglibc 2.15 with
OPTION_EGLIBC_LOCALE_CODE=n.
It seems that gcc/libstdc++-v3/acinclude.m4 doesn't check for bugs in early
glibc-2.2.x series anymore. So, it doesn't detect the lack of newlocale,
duplocale, freelocale, nl_langinfo_l an
14 matches
Mail list logo
