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?
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
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
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
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
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
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?
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
12 matches
Mail list logo