On 3/18/20 1:04 PM, Jakub Jelinek wrote:
On Wed, Mar 18, 2020 at 12:57:18PM -0600, Martin Sebor via Gcc-patches wrote:
I noticed this last night:
https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html
Presumably that's the fix.
Or maybe for REAL_TYPE just care here about TYPE_MODE
On Wed, Mar 18, 2020 at 12:57:18PM -0600, Martin Sebor via Gcc-patches wrote:
> I noticed this last night:
>
> https://sourceware.org/pipermail/glibc-cvs/2020q1/069150.html
>
> Presumably that's the fix.
Or maybe for REAL_TYPE just care here about TYPE_MODE which should be all
that matters? I
On 3/18/20 8:30 AM, Jeff Law wrote:
On Wed, 2020-03-18 at 14:25 +, Szabolcs Nagy wrote:
The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote:
On 3/12/20 7:17 PM, Joseph Myers wrote:
On Thu, 5 Mar 2020, Martin Sebor wrote:
Tested on x86_64-linux. Is this acceptable for GCC 10? How a
On Wed, 2020-03-18 at 14:25 +, Szabolcs Nagy wrote:
> The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote:
> > On 3/12/20 7:17 PM, Joseph Myers wrote:
> > > On Thu, 5 Mar 2020, Martin Sebor wrote:
> > >
> > > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
> > >
>
The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote:
> On 3/12/20 7:17 PM, Joseph Myers wrote:
> > On Thu, 5 Mar 2020, Martin Sebor wrote:
> >
> > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
> >
> > OK for GCC 10.
>
> Thank you. I committed it to trunk in r10-71
The 03/13/2020 10:45, Martin Sebor via Gcc-patches wrote:
> On 3/12/20 7:17 PM, Joseph Myers wrote:
> > On Thu, 5 Mar 2020, Martin Sebor wrote:
> >
> > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
> >
> > OK for GCC 10.
>
> Thank you. I committed it to trunk in r10-71
On Fri, 13 Mar 2020, Martin Sebor via Gcc-patches wrote:
> On 3/12/20 7:17 PM, Joseph Myers wrote:
> > On Thu, 5 Mar 2020, Martin Sebor wrote:
> >
> > > Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
> >
> > OK for GCC 10.
>
> Thank you. I committed it to trunk in r10-71
On 3/6/20 2:11 AM, Richard Biener wrote:
On Fri, Mar 6, 2020 at 2:04 AM Martin Sebor wrote:
Treating incompatible redeclarations of built-in functions as built-ins
is a problem not just for the middle-end but even for the C front-end
itself, when different parts of it make different assumptio
On 3/12/20 7:17 PM, Joseph Myers wrote:
On Thu, 5 Mar 2020, Martin Sebor wrote:
Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
OK for GCC 10.
Thank you. I committed it to trunk in r10-7162.
Do you not want me to commit it to GCC 9 or are you leaving it up to me?
Ma
On Thu, 5 Mar 2020, Martin Sebor wrote:
> Tested on x86_64-linux. Is this acceptable for GCC 10? How about 9?
OK for GCC 10.
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, Mar 6, 2020 at 2:04 AM Martin Sebor wrote:
>
> Treating incompatible redeclarations of built-in functions as built-ins
> is a problem not just for the middle-end but even for the C front-end
> itself, when different parts of it make different assumptions about
> what is and isn't valid.
Treating incompatible redeclarations of built-in functions as built-ins
is a problem not just for the middle-end but even for the C front-end
itself, when different parts of it make different assumptions about
what is and isn't valid. The test case that is the subject of this
bug report (a GCC 9
12 matches
Mail list logo