On 13/11/15 14:52, Jonathan Wakely wrote:
That patch was wrong, the new macros in include/bits/c++config used
"CSTDIO" instead of "STDIO" so it caused several tests to go from
PASS to UNSUPPORTED, oops!
This is the correct version, tested again more carefully, on
powerpc64le-linux and powerpc-ai
On 15/11/15 16:38 -0500, Jennifer Yao wrote:
I just finished running the testsuite on x86_64-pc-cygwin for
Jonathan's latest patch and compared the results against an older
(about two months old) run, and so far I'm not seeing any regressions.
Granted, this is strictly preliminary; I'm currently
> I just finished running the testsuite on x86_64-pc-cygwin for
> Jonathan's latest patch and compared the results against an older
> (about two months old) run, and so far I'm not seeing any regressions.
> Granted, this is strictly preliminary; I'm currently re-running the
> testsuite on the up-to
On 15 November 2015 at 12:14, Jonathan Wakely wrote:
> On 15/11/15 09:58 +0100, Christophe Lyon wrote:
>>
>> Ha, and my newlib copy is not very recent, it's from Oct 30th 2013:
>> maybe it's too old?
>
>
> The autoconf checks should handle old versions as well as new.
>
> The problem is I didn't c
On 15/11/15 09:58 +0100, Christophe Lyon wrote:
Ha, and my newlib copy is not very recent, it's from Oct 30th 2013:
maybe it's too old?
The autoconf checks should handle old versions as well as new.
The problem is I didn't change a defined(_GLIBCXX_USE_C99_WCHAR) to
just test its value, rather
On 14 November 2015 at 17:32, Jonathan Wakely wrote:
> On 14/11/15 09:37 +0100, Christophe Lyon wrote:
>>
>> Hi, this commit makes the GCC build to fail for targets using newlib
>> (I tested arm-none-eabi and aarch64-none-elf)
>>
>> I'm seeing errors such as:
>> In file included from
>>
>> /tmp/91
> Hi, this commit makes the GCC build to fail for targets using newlib
> (I tested arm-none-eabi and aarch64-none-elf)
>
> I'm seeing errors such as:
> In file included from
> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/inclu
On 14/11/15 09:37 +0100, Christophe Lyon wrote:
Hi, this commit makes the GCC build to fail for targets using newlib
(I tested arm-none-eabi and aarch64-none-elf)
I'm seeing errors such as:
In file included from
/tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3
On 14/11/15 09:37 +0100, Christophe Lyon wrote:
Hi, this commit makes the GCC build to fail for targets using newlib
Doh, this was supposed to *help* newlib!
I'll deal with it asap.
On 13 November 2015 at 15:52, Jonathan Wakely wrote:
> On 12/11/15 13:39 +, Jonathan Wakely wrote:
>>
>> On 12/11/15 11:40 +, Jonathan Wakely wrote:
>>>
>>> On 18/09/15 12:01 -0400, Jennifer Yao wrote:
Forgot to include the patch.
On Fri, Sep 18, 2015 at 11:17 AM, Jenni
On 12/11/15 13:39 +, Jonathan Wakely wrote:
On 12/11/15 11:40 +, Jonathan Wakely wrote:
On 18/09/15 12:01 -0400, Jennifer Yao wrote:
Forgot to include the patch.
On Fri, Sep 18, 2015 at 11:17 AM, Jennifer Yao
wrote:
A number of functions in libstdc++ are guarded by the _GLIBCXX_USE_C
On 12.11.15 14:39, Jonathan Wakely wrote:
On 12/11/15 11:40 +, Jonathan Wakely wrote:
On 18/09/15 12:01 -0400, Jennifer Yao wrote:
Forgot to include the patch.
On Fri, Sep 18, 2015 at 11:17 AM, Jennifer Yao
wrote:
A number of functions in libstdc++ are guarded by the _GLIBCXX_USE_C99
pre
On 12/11/15 12:24 -0500, Jennifer Yao wrote:
On 12/11/15 13:39 +, Jonathan Wakely wrote:
One downside of this change is that we introduce some (hopefully safe)
ODR violations, where inline functions and templates that depend on
_GLIBCXX_USE_C99_FOO might now be defined differently in C++98
> On 12/11/15 13:39 +, Jonathan Wakely wrote:
>>
>> One downside of this change is that we introduce some (hopefully safe)
>> ODR violations, where inline functions and templates that depend on
>> _GLIBCXX_USE_C99_FOO might now be defined differently in C++98 and
>> C++11 code. Previously they
On 12/11/15 13:39 +, Jonathan Wakely wrote:
One downside of this change is that we introduce some (hopefully safe)
ODR violations, where inline functions and templates that depend on
_GLIBCXX_USE_C99_FOO might now be defined differently in C++98 and
C++11 code. Previously they had the same de
On 12/11/15 11:40 +, Jonathan Wakely wrote:
On 18/09/15 12:01 -0400, Jennifer Yao wrote:
Forgot to include the patch.
On Fri, Sep 18, 2015 at 11:17 AM, Jennifer Yao
wrote:
A number of functions in libstdc++ are guarded by the _GLIBCXX_USE_C99
preprocessor macro, which is only defined on s
On 19/09/15 15:55 -0400, Jennifer Yao wrote:
Do you already have a copyright assignment for GCC?
If not, would you be willing to complete one?
No, but I would be willing to complete one, yes. Are you willing to
send me the appropriate forms, or should I contact someone else?
Great, I'll send
> Do you already have a copyright assignment for GCC?
>
> If not, would you be willing to complete one?
No, but I would be willing to complete one, yes. Are you willing to
send me the appropriate forms, or should I contact someone else?
> N.B. I don't see a patch attached to your mail, but that's
On 18/09/15 11:17 -0400, Jennifer Yao wrote:
A number of functions in libstdc++ are guarded by the _GLIBCXX_USE_C99
preprocessor macro, which is only defined on systems that pass all of
the checks for a large set of C99 functions. Consequently, on systems
which lack any of the required C99 facili
A number of functions in libstdc++ are guarded by the _GLIBCXX_USE_C99
preprocessor macro, which is only defined on systems that pass all of
the checks for a large set of C99 functions. Consequently, on systems
which lack any of the required C99 facilities (e.g. Cygwin, which
lacks some C99 complex
20 matches
Mail list logo
