Upstreaming OpenRISC with GCC mainline

Upstreaming OpenRISC with GCC mainline

[Stafford Horne]

Hello,

I currently am working through some of the final TODO items from
NewPorts[0] for upstreaming the OpenRISC GLIBC port I have been
working on.

 - make check - DONE 1 failure (tst-tzset fails to create 4GB file, my
tmp space is not big enough)
 - merged, split, cleaned up patches - DONE
 - build-many-glibcs.py - FAILS, GCC mainline warnings

Up until now I have been maintaining a patch[1] for fixing various GCC
mainline related issues to keep things moving forward.  However, the
patch does brute force tactical fixes to the warnings like setting 0
to variables when we have "maybe-uninitialized".   I was hoping by the
time I got to this point these things will be fixed.

The question now being, how should I go about upstreaming?  Should I
just backport my gcc patches to gcc-11 and move forward?  Or should I
work to fixup all of the GCC mainline issues the correct way?  I think
the second option may take quite some time though.

-Stafford

[0] https://sourceware.org/glibc/wiki/NewPorts
[1] https://github.com/stffrdhrn/or1k-glibc/commit/e4336ce6d3ea6d86e4b4db73c6acbbc6de1d2c37

Re: Upstreaming OpenRISC with GCC mainline

[Joseph Myers]

On Thu, 28 Oct 2021, Stafford Horne via Libc-alpha wrote:

> The question now being, how should I go about upstreaming?  Should I
> just backport my gcc patches to gcc-11 and move forward?  Or should I
> work to fixup all of the GCC mainline issues the correct way?  I think
> the second option may take quite some time though.

What are you doing differently in your GCC or glibc ports that results in 
getting these warnings for OpenRISC but not for other architectures?  
That's a key thing to understand, separately for each issue (for example, 
S/390 sometimes has problems with warnings not seen on other architectures 
because it sets various tuning parameters differently).  In some cases, it 
might be that GCC *should* warn for other architectures, in which case an 
upstream GCC bug needs reporting about the missing warning.  For example, 
I can see no good reason for the "'strcmp' argument 2 declared attribute 
'nonstring'" warnings you quote to depend on the architecture; they should 
appear on all architectures or none.

Then, if a warning is a false positive (and really is still present with 
current GCC mainline), adding an initialization is not normally the 
appropriate fix; rather, for uninitialized warnings we use DIAG_* to 
suppress them, with a comment explaining the analysis of *why* the warning 
is a false positive.  For example, in sysdeps/ieee754/flt-32/s_log1pf.c we 
already have a use of those macros for what looks like the specific 
warning case you quote; if, despite that, you see the warning for a 
different place in the same file for the same variable, it might be 
reasonable to repeat the same macro calls and comment there, if the same 
analysis applies.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Upstreaming OpenRISC with GCC mainline

[Stafford Horne]

On Thu, Oct 28, 2021, 7:13 AM Joseph Myers <joseph@codesourcery.com> wrote:

> On Thu, 28 Oct 2021, Stafford Horne via Libc-alpha wrote:
>
> > The question now being, how should I go about upstreaming?  Should I
> > just backport my gcc patches to gcc-11 and move forward?  Or should I
> > work to fixup all of the GCC mainline issues the correct way?  I think
> > the second option may take quite some time though.
>
> What are you doing differently in your GCC or glibc ports that results in
> getting these warnings for OpenRISC but not for other architectures?
> That's a key thing to understand, separately for each issue (for example,
> S/390 sometimes has problems with warnings not seen on other architectures
> because it sets various tuning parameters differently).  In some cases, it
> might be that GCC *should* warn for other architectures, in which case an
> upstream GCC bug needs reporting about the missing warning.  For example,
> I can see no good reason for the "'strcmp' argument 2 declared attribute
> 'nonstring'" warnings you quote to depend on the architecture; they should
> appear on all architectures or none.
>
> Then, if a warning is a false positive (and really is still present with
> current GCC mainline), adding an initialization is not normally the
> appropriate fix; rather, for uninitialized warnings we use DIAG_* to
> suppress them, with a comment explaining the analysis of *why* the warning
> is a false positive.  For example, in sysdeps/ieee754/flt-32/s_log1pf.c we
> already have a use of those macros for what looks like the specific
> warning case you quote; if, despite that, you see the warning for a
> different place in the same file for the same variable, it might be
> reasonable to repeat the same macro calls and comment there, if the same
> analysis applies.


Hi Joseph,

Thanks for the comments.  I have been watching the testsresults mails:

  https://sourceware.org/pipermail/libc-testresults/2021q4/008772.html
  https://sourceware.org/pipermail/libc-testresults/2021q4/008773.html

I was seeing failures there and thought the warnings I was seeing were
affecting all architectures.  But now I see the builds are mostly clean.
So it's something I'll have to track down.

Now with your input I have some ideas. If I do need patches I'll use the
proper DIAG_* macros as you mentioned. I am familiar with those.

-Stafford

Re: Upstreaming OpenRISC with GCC mainline

[Joseph Myers]

On Thu, 28 Oct 2021, Stafford Horne via Libc-alpha wrote:

> I was seeing failures there and thought the warnings I was seeing were
> affecting all architectures.  But now I see the builds are mostly clean.
> So it's something I'll have to track down.

The only issue I know of at present with GCC mainline is the testsuite 
build failures for 32-bit platforms that are addressed by my patch 
<https://sourceware.org/pipermail/libc-alpha/2021-October/132348.html>.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Upstreaming OpenRISC with GCC mainline

[Stafford Horne]

On Thu, Oct 28, 2021 at 05:15:00PM +0000, Joseph Myers wrote:
> On Thu, 28 Oct 2021, Stafford Horne via Libc-alpha wrote:
> 
> > I was seeing failures there and thought the warnings I was seeing were
> > affecting all architectures.  But now I see the builds are mostly clean.
> > So it's something I'll have to track down.
> 
> The only issue I know of at present with GCC mainline is the testsuite 
> build failures for 32-bit platforms that are addressed by my patch 
> <https://sourceware.org/pipermail/libc-alpha/2021-October/132348.html>.

Thanks, yes I saw that patch.

I am trying to compare builds of multiple architectures.  I do see similar
errors on riscv32.  I am continuing to try looking at other architectures, but
just wanted to note this:

FAIL: compilers-riscv32-linux-gnu-rv32imac-ilp32 glibc riscv32-linux-gnu-rv32imac-ilp32 build

    malloc.c: In function ‘_int_malloc’:
    malloc.c:4226:53: error: ‘nb’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     4226 |                   set_head (victim, nb | PREV_INUSE |
	  |                                                     ^
    malloc.c:3657:19: note: ‘nb’ was declared here
     3657 |   INTERNAL_SIZE_T nb;               /* normalized request size */
	  |                   ^~

FAIL: compilers-or1k-linux-gnu-soft glibc or1k-linux-gnu-soft build

    malloc.c: In function ‘_int_malloc’:
    malloc.c:4226:53: error: ‘nb’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
     4226 |                   set_head (victim, nb | PREV_INUSE |
	  |                                                     ^
    malloc.c:3657:19: note: ‘nb’ was declared here
     3657 |   INTERNAL_SIZE_T nb;               /* normalized request size */
	  |                   ^~

GCC: mainline   (2021-10-29 308531d148a)
GLIBC: mainline (2021-10-19 46baeb61e1)

Ill try to update GLIBC.

-Stafford

Re: Upstreaming OpenRISC with GCC mainline

[Joseph Myers]

On Fri, 29 Oct 2021, Stafford Horne via Libc-alpha wrote:

> On Thu, Oct 28, 2021 at 05:15:00PM +0000, Joseph Myers wrote:
> > On Thu, 28 Oct 2021, Stafford Horne via Libc-alpha wrote:
> > 
> > > I was seeing failures there and thought the warnings I was seeing were
> > > affecting all architectures.  But now I see the builds are mostly clean.
> > > So it's something I'll have to track down.
> > 
> > The only issue I know of at present with GCC mainline is the testsuite 
> > build failures for 32-bit platforms that are addressed by my patch 
> > <https://sourceware.org/pipermail/libc-alpha/2021-October/132348.html>.
> 
> Thanks, yes I saw that patch.
> 
> I am trying to compare builds of multiple architectures.  I do see similar
> errors on riscv32.  I am continuing to try looking at other architectures, but
> just wanted to note this:
> 
> FAIL: compilers-riscv32-linux-gnu-rv32imac-ilp32 glibc riscv32-linux-gnu-rv32imac-ilp32 build

Since I don't see this, do you have environment variables set (e.g. 
CFLAGS) that might perturb the build?  You're not meant to have such 
variables set when running build-many-glibcs.py, and can definitely expect 
additional warnings with -O1 or -O3, for example.  (We *should* fix things 
to build cleanly with -O1 and -O3 and -Os and -Og, and even -O0, but 
that's a separate issue.)

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Upstreaming OpenRISC with GCC mainline

[Stafford Horne]

On Thu, Oct 28, 2021 at 09:45:51PM +0000, Joseph Myers wrote:
> On Fri, 29 Oct 2021, Stafford Horne via Libc-alpha wrote:
> 
> > On Thu, Oct 28, 2021 at 05:15:00PM +0000, Joseph Myers wrote:
> > > On Thu, 28 Oct 2021, Stafford Horne via Libc-alpha wrote:
> > > 
> > > > I was seeing failures there and thought the warnings I was seeing were
> > > > affecting all architectures.  But now I see the builds are mostly clean.
> > > > So it's something I'll have to track down.
> > > 
> > > The only issue I know of at present with GCC mainline is the testsuite 
> > > build failures for 32-bit platforms that are addressed by my patch 
> > > <https://sourceware.org/pipermail/libc-alpha/2021-October/132348.html>.
> > 
> > Thanks, yes I saw that patch.
> > 
> > I am trying to compare builds of multiple architectures.  I do see similar
> > errors on riscv32.  I am continuing to try looking at other architectures, but
> > just wanted to note this:
> > 
> > FAIL: compilers-riscv32-linux-gnu-rv32imac-ilp32 glibc riscv32-linux-gnu-rv32imac-ilp32 build
> 
> Since I don't see this, do you have environment variables set (e.g. 
> CFLAGS) that might perturb the build?  You're not meant to have such 
> variables set when running build-many-glibcs.py, and can definitely expect 
> additional warnings with -O1 or -O3, for example.  (We *should* fix things 
> to build cleanly with -O1 and -O3 and -Os and -Og, and even -O0, but 
> that's a separate issue.)

Thats it, I have -Og setup in my build environment.

I must have missed where that was mentioned.

-Stafford

Re: Upstreaming OpenRISC with GCC mainline

[Stafford Horne]

On Fri, Oct 29, 2021 at 07:18:45AM +0900, Stafford Horne wrote:
> On Thu, Oct 28, 2021 at 09:45:51PM +0000, Joseph Myers wrote:
> > On Fri, 29 Oct 2021, Stafford Horne via Libc-alpha wrote:
> > 
> > > On Thu, Oct 28, 2021 at 05:15:00PM +0000, Joseph Myers wrote:
> > > > On Thu, 28 Oct 2021, Stafford Horne via Libc-alpha wrote:
> > > > 
> > > > > I was seeing failures there and thought the warnings I was seeing were
> > > > > affecting all architectures.  But now I see the builds are mostly clean.
> > > > > So it's something I'll have to track down.
> > > > 
> > > > The only issue I know of at present with GCC mainline is the testsuite 
> > > > build failures for 32-bit platforms that are addressed by my patch 
> > > > <https://sourceware.org/pipermail/libc-alpha/2021-October/132348.html>.
> > > 
> > > Thanks, yes I saw that patch.
> > > 
> > > I am trying to compare builds of multiple architectures.  I do see similar
> > > errors on riscv32.  I am continuing to try looking at other architectures, but
> > > just wanted to note this:
> > > 
> > > FAIL: compilers-riscv32-linux-gnu-rv32imac-ilp32 glibc riscv32-linux-gnu-rv32imac-ilp32 build
> > 
> > Since I don't see this, do you have environment variables set (e.g. 
> > CFLAGS) that might perturb the build?  You're not meant to have such 
> > variables set when running build-many-glibcs.py, and can definitely expect 
> > additional warnings with -O1 or -O3, for example.  (We *should* fix things 
> > to build cleanly with -O1 and -O3 and -Os and -Og, and even -O0, but 
> > that's a separate issue.)
> 
> Thats it, I have -Og setup in my build environment.
> 
> I must have missed where that was mentioned.
> 

Hi Joseph,

Do you store your full output results anywhere for build-many, i.e.

 GCC mainline glibcs 2021-10-28 16:33:56 build results
 - https://sourceware.org/pipermail/libc-testresults/2021q4/008777.html

I am getting these failures now, and am wondering if you see them too:

    $ or1k-glibc-linux-gnu-gcc tst-mqueue5.c -c -std=gnu11 -fgnu89-inline  -g -O -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fno-stack-protector -fno-c....
    tst-mqueue5.c: In function ‘mqsend’:
    tst-mqueue5.c:61:7: error: ‘c’ may be used uninitialized [-Werror=maybe-uninitialized]
       61 |   if (mq_send (q, &c, 1, 1) != 0)
	  |       ^~~~~~~~~~~~~~~~~~~~~
    In file included from ../include/mqueue.h:1,
		     from tst-mqueue5.c:21:
    ../rt/mqueue.h:70:12: note: by argument 2 of type ‘const char *’ to ‘mq_send’ declared here
       70 | extern int mq_send (mqd_t __mqdes, const char *__msg_ptr, size_t __msg_len,
	  |            ^~~~~~~
    tst-mqueue5.c:60:8: note: ‘c’ declared here
       60 |   char c;
	  |        ^

-Stafford

Re: Upstreaming OpenRISC with GCC mainline

[Joseph Myers]

On Fri, 29 Oct 2021, Stafford Horne wrote:

>     $ or1k-glibc-linux-gnu-gcc tst-mqueue5.c -c -std=gnu11 -fgnu89-inline  -g -O -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fno-stack-protector -fno-c....

That's -O, i.e. -O1, which is expected to have extra warnings.  Making 
glibc build cleanly with different optimization options would be good, but 
should be handled separately from new ports.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Upstreaming OpenRISC with GCC mainline

[Stafford Horne]

On Fri, Oct 29, 2021, 11:43 PM Joseph Myers <joseph@codesourcery.com> wrote:

> On Fri, 29 Oct 2021, Stafford Horne wrote:
>
> >     $ or1k-glibc-linux-gnu-gcc tst-mqueue5.c -c -std=gnu11
> -fgnu89-inline  -g -O -Wall -Wwrite-strings -Wundef -Werror
> -fmerge-all-constants -frounding-math -fno-stack-protector -fno-c....
>
> That's -O, i.e. -O1, which is expected to have extra warnings.  Making
> glibc build cleanly with different optimization options would be good, but
> should be handled separately from new ports.
>

Oh, you are right, I reset CFLAGS before the build so I didn't think
anything would be coming in. I'll try to figure out where those extra flags
are coming from.

>

Re: Upstreaming OpenRISC with GCC mainline

[Stafford Horne]

On Sat, Oct 30, 2021 at 12:08:18AM +0900, Stafford Horne wrote:
> On Fri, Oct 29, 2021, 11:43 PM Joseph Myers <joseph@codesourcery.com> wrote:
> 
> > On Fri, 29 Oct 2021, Stafford Horne wrote:
> >
> > >     $ or1k-glibc-linux-gnu-gcc tst-mqueue5.c -c -std=gnu11
> > -fgnu89-inline  -g -O -Wall -Wwrite-strings -Wundef -Werror
> > -fmerge-all-constants -frounding-math -fno-stack-protector -fno-c....
> >
> > That's -O, i.e. -O1, which is expected to have extra warnings.  Making
> > glibc build cleanly with different optimization options would be good, but
> > should be handled separately from new ports.
> >
> 
> Oh, you are right, I reset CFLAGS before the build so I didn't think
> anything would be coming in. I'll try to figure out where those extra flags
> are coming from.

Alright, now that I am using -g -O2 I am almost getting a clean run of
build-many-glibcs.py, using the following branches:

    GLIBC: mainline (2021-10-29 b3cf94ef15 + or1k port)
    GCC  : mainline (2021-10-29 518bc4ef87e)

I am now getting the below for both x86_64-linux-gnu and or1k-linux-gnu-soft.

It seems to be related to -frounding-math, removing that flag fixes the issue.
GCC has 2 patches related to this recently committed:

   2021-10-28 81342e95827 Richard Biener   middle-end/84407 - honor -frounding-math for int to float conversion
   2021-10-28 a84b9d5373c Richard Biener   middle-end/57245 - honor -frounding-math in real truncation

Error:

    or1k-glibc-linux-gnu-gcc tst-timespec.c -fdump-analyzer -fdump-lang-all -fdump-tree-all -c -fgnu89-inline  -g -O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition -fmath-errno            -I../include -I/home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support  -I/home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc  -I../sysdeps/unix/sysv/linux/or1k  -I../sysdeps/or1k/nptl  -I../sysdeps/unix/sysv/linux/generic/wordsize-32  -I../sysdeps/unix/sysv/linux/generic  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/or1k/nofpu  -I../sysdeps/ieee754/soft-fp  -I../sysdeps/or1k  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.  -D_LIBC_REENTRANT -include /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/libc-modules.h -DMODULE_NAME=testsuite -include ../include/libc-symbols.h       -DTOP_NAMESPACE=glibc -o /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o -MD -MP -MF /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o.dt -MT /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o
    In file included from tst-timespec.c:22:
    ../include/intprops.h:57:3: error: initializer element is not computable at load time
       57 |   ((t) (! TYPE_SIGNED (t)                                               \
	  |   ^
    tst-timespec.c:48:20: note: in expansion of macro ‘TYPE_MAXIMUM’
       48 | #define TIME_T_MAX TYPE_MAXIMUM (time_t)
	  |                    ^~~~~~~~~~~~
    tst-timespec.c:290:19: note: in expansion of macro ‘TIME_T_MAX’
      290 |    .upper_bound = TIME_T_MAX, .lower_bound = 1, .result = 1,
	  |                   ^~~~~~~~~~
    ../include/intprops.h:57:3: note: (near initialization for ‘check_cases[20].upper_bound’)
       57 |   ((t) (! TYPE_SIGNED (t)                                               \
	  |   ^
    tst-timespec.c:48:20: note: in expansion of macro ‘TYPE_MAXIMUM’
       48 | #define TIME_T_MAX TYPE_MAXIMUM (time_t)
	  |                    ^~~~~~~~~~~~
    tst-timespec.c:290:19: note: in expansion of macro ‘TIME_T_MAX’
      290 |    .upper_bound = TIME_T_MAX, .lower_bound = 1, .result = 1,
	  |                   ^~~~~~~~~~

So maybe we need some more DIAG_* macros here now?

-Stafford

Re: Upstreaming OpenRISC with GCC mainline

[Joseph Myers]

On Sat, 30 Oct 2021, Stafford Horne via Libc-alpha wrote:

> Error:
> 
>     or1k-glibc-linux-gnu-gcc tst-timespec.c -fdump-analyzer -fdump-lang-all -fdump-tree-all -c -fgnu89-inline  -g -O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition -fmath-errno            -I../include -I/home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support  -I/home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc  -I../sysdeps/unix/sysv/linux/or1k  -I../sysdeps/or1k/nptl  -I../sysdeps/unix/sysv/linux/generic/wordsize-32  -I../sysdeps/unix/sysv/linux/generic  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/or1k/nofpu  -I../sysdeps/ieee754/soft-fp  -I../sysdeps/or1k  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.  -D_LIBC_REENTRANT -include /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/libc-modules.h -DMODULE_NAME=testsuite -include ../include/libc-symbols.h       -DTOP_NAMESPACE=glibc -o /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o -MD -MP -MF /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o.dt -MT /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o
>     In file included from tst-timespec.c:22:
>     ../include/intprops.h:57:3: error: initializer element is not computable at load time
>        57 |   ((t) (! TYPE_SIGNED (t)                                               \
> 	  |   ^
>     tst-timespec.c:48:20: note: in expansion of macro ‘TYPE_MAXIMUM’
>        48 | #define TIME_T_MAX TYPE_MAXIMUM (time_t)
> 	  |                    ^~~~~~~~~~~~
>     tst-timespec.c:290:19: note: in expansion of macro ‘TIME_T_MAX’
>       290 |    .upper_bound = TIME_T_MAX, .lower_bound = 1, .result = 1,
> 	  |                   ^~~~~~~~~~
>     ../include/intprops.h:57:3: note: (near initialization for ‘check_cases[20].upper_bound’)
>        57 |   ((t) (! TYPE_SIGNED (t)                                               \
> 	  |   ^
>     tst-timespec.c:48:20: note: in expansion of macro ‘TYPE_MAXIMUM’
>        48 | #define TIME_T_MAX TYPE_MAXIMUM (time_t)
> 	  |                    ^~~~~~~~~~~~
>     tst-timespec.c:290:19: note: in expansion of macro ‘TIME_T_MAX’
>       290 |    .upper_bound = TIME_T_MAX, .lower_bound = 1, .result = 1,
> 	  |                   ^~~~~~~~~~
> 
> So maybe we need some more DIAG_* macros here now?

No, since (a) this is a plain error, not a warning that's turned to an 
error by -Werror, so DIAG_* can't help, and (b) it's a definite compiler 
bug that needs to be fixed in GCC.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103031

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Upstreaming OpenRISC with GCC mainline

[Stafford Horne]

On Mon, Nov 01, 2021 at 08:47:04PM +0000, Joseph Myers wrote:
> On Sat, 30 Oct 2021, Stafford Horne via Libc-alpha wrote:
> 
> > Error:
> > 
> >     or1k-glibc-linux-gnu-gcc tst-timespec.c -fdump-analyzer -fdump-lang-all -fdump-tree-all -c -fgnu89-inline  -g -O2 -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fno-stack-protector -fno-common -Wstrict-prototypes -Wold-style-definition -fmath-errno            -I../include -I/home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support  -I/home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc  -I../sysdeps/unix/sysv/linux/or1k  -I../sysdeps/or1k/nptl  -I../sysdeps/unix/sysv/linux/generic/wordsize-32  -I../sysdeps/unix/sysv/linux/generic  -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv  -I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/or1k/nofpu  -I../sysdeps/ieee754/soft-fp  -I../sysdeps/or1k  -I../sysdeps/wordsize-32  -I../sysdeps/ieee754/dbl-64  -I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754  -I../sysdeps/generic  -I.. -I../libio -I.  -D_LIBC_REENTRANT -include /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/libc-modules.h -DMODULE_NAME=testsuite -include ../include/libc-symbols.h       -DTOP_NAMESPACE=glibc -o /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o -MD -MP -MF /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o.dt -MT /home/shorne/work/gnu-toolchain/build-many/build/glibcs/or1k-linux-gnu-soft/glibc/support/tst-timespec.o
> >     In file included from tst-timespec.c:22:
> >     ../include/intprops.h:57:3: error: initializer element is not computable at load time
> >        57 |   ((t) (! TYPE_SIGNED (t)                                               \
> > 	  |   ^
> >     tst-timespec.c:48:20: note: in expansion of macro ‘TYPE_MAXIMUM’
> >        48 | #define TIME_T_MAX TYPE_MAXIMUM (time_t)
> > 	  |                    ^~~~~~~~~~~~
> >     tst-timespec.c:290:19: note: in expansion of macro ‘TIME_T_MAX’
> >       290 |    .upper_bound = TIME_T_MAX, .lower_bound = 1, .result = 1,
> > 	  |                   ^~~~~~~~~~
> >     ../include/intprops.h:57:3: note: (near initialization for ‘check_cases[20].upper_bound’)
> >        57 |   ((t) (! TYPE_SIGNED (t)                                               \
> > 	  |   ^
> >     tst-timespec.c:48:20: note: in expansion of macro ‘TYPE_MAXIMUM’
> >        48 | #define TIME_T_MAX TYPE_MAXIMUM (time_t)
> > 	  |                    ^~~~~~~~~~~~
> >     tst-timespec.c:290:19: note: in expansion of macro ‘TIME_T_MAX’
> >       290 |    .upper_bound = TIME_T_MAX, .lower_bound = 1, .result = 1,
> > 	  |                   ^~~~~~~~~~
> > 
> > So maybe we need some more DIAG_* macros here now?
> 
> No, since (a) this is a plain error, not a warning that's turned to an 
> error by -Werror, so DIAG_* can't help, and (b) it's a definite compiler 
> bug that needs to be fixed in GCC.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103031

Thanks for explaining.

For now I am just adding a cast using (double) to work around this.  A recent
rebase has introduced an abort localplt symbol into libc.so, so
build-many-glibs.py is not clean for me anylonger.

Once I track that down I should be good to submit v2 of the port for review.

-Stafford