Re: Cortex M0 Floating Point Library

2018-11-11 Thread Richard Henderson 
On 11/9/18 9:58 PM, Daniel Engel wrote:
> Is the linker aware of section hierarchy, such that using a common section 
> prefix (e.g. ".text.m0fp.*") would gather the appropriate sections together 
> from multiple object files?

The linker script is not written like that.  But we could reasonably replace
the current ".text.*" with "SORT(.text.*)" with no ill effects (since the
current ordering is not guaranteed, no one should be depending on it).

> Adding such rules to the default linker script wouldn't be ideal, as everyone 
> using a custom script might then have library breakage unless they knew to 
> add equivalent rules.

*shrug* But what other solution?  At least the failure isn't silent -- the
branches will be out of range and the link will fail.  Anyone using their own
linker script must be willing to adjust to compiler changes over time, and in
this case the fix is trivial.

> If the consensus is to split the library, it might help to add a set of 
> intermediate branches (trampolines?) in the libm portion.  This would add 
> execution cycles, but not require as many extra bytes.

I don't think it's a good idea to put sin() into libgcc.  That really does
belong over in newlib.  Trampolines do sound like a reasonable solution.


r~

Re: A GCC bug related to inline?

2018-11-11 Thread Jakub Jelinek 
On Sun, Nov 11, 2018 at 02:58:26PM +0800, Bin.Cheng wrote:
> Given below simple code:
> 
> inline int foo (int a) {
>   return a + 1;
> }
> int g = 5;
> int main(void) {
>   return foo(g);
> }

This is the standard C99 inlining behavior.  inline means
provide something that can be inlined, but don't generate an external
definition.  One needs to use the extern keyword in one of the TUs to emit
it.  See
https://gcc.gnu.org/onlinedocs/gcc/Inline.html
https://gcc.gnu.org/gcc-4.2/changes.html
for more info.  You can use -fgnu89-inline, or -std=gnu89, or gnu_inline
attribute if you are looking for the GNU inlining semantics rather than C99
one.  And of course, in C++ the inlining behavior is yet different (comdat).

Jakub

gcc-9-20181111 is now available

2018-11-11 Thread gccadmin 
Snapshot gcc-9-2018 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/9-2018/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 266019

You'll find:

 gcc-9-2018.tar.xzComplete GCC

  SHA256=b6cdafca386ff918dc4f2293d0f9bad2185c597f91ce31154e226fdfa5f320fd
  SHA1=5f620edb91e7e0ce0ed410dd95fb0fb4da808bb0

Diffs from 9-20181104 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-9
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: [PATCH v3 1/3] or1k: libgcc: initial support for openrisc

2018-11-11 Thread Sebastian Huber 

Hello Stafford,

I tried to build the or1k-rtems5 target with GCC 
4c0c3d1029e79b6709b43fed8c5a5944f245516d and Binutils 
417e50dbcfd4b8dd699f48df5ac9b9a733fd80e2. It failed in the libgcc build:


/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/./gcc/xgcc 
-B/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/./gcc/ 
-nostdinc 
-B/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/or1k-rtems5/mcmov/newlib/ 
-isystem 
/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/build/or1k-rtems5/mcmov/newlib/targ-include 
-isystem 
/scratch/git-rtems-source-builder/rtems/build/or1k-rtems5-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d-newlib-2ab57ad59bc35dafffa69cd4da5e228971de069f-x86_64-linux-gnu-1/gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/newlib/libc/include 
-B/build/rtems/5/or1k-rtems5/bin/ -B/build/rtems/5/or1k-rtems5/lib/ 
-isystem /build/rtems/5/or1k-rtems5/include -isystem 
/build/rtems/5/or1k-rtems5/sys-include  -mcmov -g -O2 -O2 
-I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../newlib/libc/sys/rtems/include 
-g -O2 -DIN_GCC  -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing 
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition  -isystem ./include -g -DIN_LIBGCC2 
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc  -I. -I. 
-I../../.././gcc 
-I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc 
-I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/. 
-I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../gcc 
-I../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/../include 
-o _ffssi2.o -MT _ffssi2.o -MD -MP -MF _ffssi2.dep -DL_ffssi2 -c 
../../../../gnu-mirror-gcc-4c0c3d1029e79b6709b43fed8c5a5944f245516d/libgcc/libgcc2.c 
-fvisibility=hidden -DHIDE_EXPORTS -save-temps

libgcc2.s: Assembler messages:
libgcc2.s:60: Error: junk at end of line `l.movhi r17,ha(__clz_tab)'

The file content in this area is:

.L4:
.LVL4:
.LM17:
.LBE3:
.LM18:
.LBE2:
.LM19:
.LBB6:
.LBB4:
.LM20:
    l.movhi    r17, ha(__clz_tab)
    l.addi    r17, r17, lo(__clz_tab)
    l.add    r3, r17, r3
.LVL5:
    l.lbz    r11, 0(r3)

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.