Re: [resend] implement assembly variant routines for IEEE floating-point under libgcc for cortex-m0

[Joey Ye]

Mallikarjun,

Thanks for trying this. I agree with you that current C implementation
is far from optimal.

It is in our road-map with a different approach, which will not simply
port current functions from armv7-m to armv6-m. This task is low
priority due to less common usage of fp in Cortex-M0*, so it may take
years to show up in mainline.

Thanks,
Joey

On Mon, Aug 4, 2014 at 2:40 PM, Mallikarjun Goudar
 wrote:
> Hi All,
>
> sorry, sending previous mail with proper subject line.
>
> For cortex-m0 (armv6-m) target, i observed that ieee floating-point
> functions under libgcc are implemented in C.
> This takes lot of memory if one uses floating-point in their
> applciations. I agree that usage of fp in cortex-m0 devices might be
> minimal.
>
> I wanted to check if its good idea to implement these fp functions in
> assembly. As we have already assembly variant functions for cortex-m4
> (armv7-m) targets,
> It would be nice to port those to armv6-m. I have ported couple of
> routines as an exercise. And results looked good. I see
> improvement in size and speed. I ran some fp tests on hardware board
> to see the performance.
>
> I would be interested in porting remaining functions and contribute to
> the community. I am open to discussion on this.
> Please reply if you feel its good idea to implement this feature.
>
> If anyone has already working on this, please let me know.
>
> Thanks,
> Mallikarjuna

Is escaping of a temp variable valid?

[Joey Ye]

Running into an unexpected result with GCC with following case, but
not sure if it is a valid C++ case.

#define nullptr 0
enum nonetype { none };

template
class class_zoo {
  public:
const T *data;
int length;

class_zoo (nonetype) : data (nullptr), length (0) {}
class_zoo (const T &e) : data (&e), length (1) {}
};

int bar (class_zoo p1 = none,
 class_zoo p2 = none)
{
  if (*p1.data==nullptr) return 1;
  return 0;
}

int foo (int *b)   // If changing int to const int here, zoo will
return 0 (pass)
{
  class_zoo zoo(b);
  return bar(zoo);
}

int g = 678;
int main ()
{
  return foo (&g);
}

$ g++  main.cpp -fstack-protector -o m
$ ./m
$ echo $?
1

Expand shows:
D.2320 = b_2(D);
  class_zoo::class_zoo (&zoo, &D.2320);
  D.2320 ={v} {CLOBBER};<--- D.2320 is dead, but it is address
escapes to zoo
   <--- with
stack-protector, D.2322 reuses stack slot of D.2320, thus overwrite
D.2320
  class_zoo::class_zoo (&D.2322, 0);
  _8 = bar (zoo, D.2322);< D.2320 is accessed via its
address, but value changed now
  _9 = _8;
  D.2322 ={v} {CLOBBER};
  zoo ={v} {CLOBBER};
;;succ:   3

;;   basic block 3, loop depth 0
;;pred:   2
:
  return _9;
;;succ:   EXIT

}


Partition 0: size 16 align 16
D.2322  D.2320  <--- GCC believes they are not
conflict, which is what I not sure of here
Partition 2: size 16 align 16
zoo

Questions
1. Is this a correct test case?
2. If not, why escaping of D.2320's address to a local is not
accounted as conflicting to other local variables?

Thanks,
Joey

Re: Is escaping of a temp variable valid?

[Joey Ye]

On Fri, Aug 15, 2014 at 6:33 PM, Richard Biener
 wrote:
> On Fri, Aug 15, 2014 at 10:45 AM, Joey Ye  wrote:
>> Running into an unexpected result with GCC with following case, but
>> not sure if it is a valid C++ case.
>>
>> #define nullptr 0
>> enum nonetype { none };
>>
>> template
>> class class_zoo {
>>   public:
>> const T *data;
>> int length;
>>
>> class_zoo (nonetype) : data (nullptr), length (0) {}
>> class_zoo (const T &e) : data (&e), length (1) {}
>
> Capturing a const referece via a pointer is error-prone as for
> example literal constants class_zoo zoo(0)
> have associated objects that live only throughout the function
> call.
Thanks for confirming this. But do you imply capturing a non-const
reference via a pointer is safe, which I would assume it unsafe
either?

- Joey
>
> So clearly your testcase is invalid.
>
> Richard.

Re: RFD: selective linking of floating point support for *printf / *scanf

[Joey Ye]

Joern, there is https://sourceware.org/ml/newlib/2014/msg00166.html,
which is already in newlib mainline. I think it solves the same issue
in a slight different approach.

Does it work for you?

Thanks,
Joey

On Thu, Aug 14, 2014 at 4:52 PM, Joern Rennecke
 wrote:
> For embedded targets with small memories and static linking, the size of
> functions like *printf and their dependencies is painful, particularily for
> targets that need software floating point.
>
> avr-libc has long had a printf / scanf implementation that by default does not
> include floating point support.  There's a library that can be liked to 
> provide
> the floating-point enabled functions, but the required functions have
> to be pulled
> in manually with -Wl,-u if they are otherwise only referenced from libc, lest
> these symbols got resolved with the integer-only implementations from
> libc itself.
> All in all, a rather unsatisfying state of affairs when trying to run the
> gcc regression test suite.
>
> Newlib also has an integer-only printf implementation, but in this case,
> the default is the other way round - you have to use functions with 
> nonstandard
> names to use the integer-only implementations.  And a half-hearted approach to
> use this can easily end up with linking in both the integer-only version and 
> the
> floating-point enabled one, resulting in increased executable size instead of
> a saving.
>
> I think we can do better with integrated compiler/linker support.
> Trying to do a perfect job i of course impossible because of Rice's theorem,
> but it doesn't have to be perfect to be useful.
> Just looking statically at each *printf statement, we can look at the format
> strings and/or the passed arguments.
> Floating point arguments are easier to check for by the compiler than parsing
> the format string.  There is already code that parses the format strings for 
> the
> purpose of warnings, but it would be a somewhat intrusive change to add this
> functionality there, and the information is not available where a variable
> format is used anyway.
> In a standards-conformant application, floating point formats can only be used
> with floating point arguments, so checking for the latter seems most 
> effective.
>
> So my idea is to make the compile emit special calls when there are no 
> floating
> point arguments.  A library that provides the floating point enabled
> *printf/*scanf
> precedes libc in link order.
> Libc contains the integer-only implementations of *scanf/*printf, in two 
> parts:
> entry points with the special function name, which in the same object file
> also contain a reference to the ordinary function name, and another object 
> file
> with the ordinary symbol and the integer-only implementation.
> Thus, if any application translation unit has pulled in a floating-point 
> enabled
> implementation, this is the one that'll be used.  Otherwise, the integer-only
> one will be used.
> Use of special sections and alphasorting of these in the linker script
> ensures that the integer-only entry points appear in the right place at
> the start of the chosen implementation.
> If vfprintf is used
>
> I've implemented this for AVR with these commits:
> https://github.com/embecosm/avr-gcc/commit/3b3bfe33fe29b6d29d8fb96e5d57ee025adf7af0
> https://github.com/embecosm/avr-libc/commit/c55eba74838635613c8b80d86a85ed605a79d337
> https://github.com/embecosm/avr-binutils-gdb/commit/72b3a1ea3659577198838a7149c6882a079da403
>
> Although it could use some more testing, and thought how to best
> introduce the change as to avoid getting broken toolchains when components
> are out-of-sync.
>
> Now Joerg Wunsch suggested we might want to facto out more pieces, like the
> long long support.  This quickly leads to a combinatorial explosion.
> If we want to support a more modular *printf / *scanf, than maybe a different
> approach is warranted.
> Say, if we could give a symbol and section attribute and/or pragma to 
> individual
> case labels of a switch, and put the different pieces into separate object
> files (maybe with a bit of objcopy massaging).
> The symbols references to trigger the inclusion of the case objects could be
> generated by the gcc backend by processing suitably annotated function calls.
> E.g. we might put something into CALL_FUNCTION_USAGE, or play with
> TARGET_ENCODE_SECTION_INFO.

Re: selective linking of floating point support for *printf / *scanf

[Joey Ye]

On Sat, Aug 30, 2014 at 12:26 PM, Thomas Preud'homme
 wrote:
>> From: Grissiom [mailto:chaos.pro...@gmail.com]
>> Sent: Friday, August 29, 2014 11:51 PM
>>
>> Yes, it does.  The namespace reserved for the implementation is _[_A-Z].
>  > The namespace _[a-z] is still available for the user.  Which means the
>> user can declare their own _printf_float, and WE (as the implementation)
>> MUST NOT INTERFERE with it.  Since WE are the implementation, we should
>> use the namespace reserved for us, namely __printf_float.
>
> Mmmh indeed. I checked C99 and section 7.1.3 paragraph 1 third clause states:
>
> "All identifiers that begin with an underscore and either an uppercase letter 
> or
> another underscore are always reserved for any use."
>
> Next clause express how single underscore not followed by a capital letter is
> reserved:
>
> "All identifiers that begin with an underscore are always reserved for use as 
> identifiers
> with file scope in both the ordinary and tag name spaces."
Apparently newlib is not following this specification very well, as
there are symbols like _abc_r defined every where in current newlib. I
am not implying the spec should not be followed, but is newlib
designed to have a loose spec for the single underscore?

- Joey

>
> Since here we are talking about linkage, _printf_float is not safe according 
> to the
> standard.
>
> Sigh.
>
> Ok I need to think about it. Thank you all for pointing out the problem with 
> the
> current scheme.
>
> Best regards,
>
> Thomas
>
>

Re: plugins header file

[Joey Ye]

Sounds a good idea to me, here is the list I'm using:
#include "params.h"
#include "flags.h"
#include "tree.h"
#include "tree-pass.h"
#include "basic-block.h"
#include "function.h"
#include "hash-table.h"
#include "tree-ssa-alias.h"
#include "tree-cfg.h"
#include "tree-ssa-operands.h"
#include "tree-inline.h"
#include "gimple-expr.h"
#include "is-a.h"
#include "gimple.h"
#include "tree-phinodes.h"
#include "gimple-iterator.h"
#include "gimple-ssa.h"
#include "ssa-iterators.h"
#include "tree-into-ssa.h"
#include "cfgloop.h"
#include "context.h"

However, it does not automatically solve the missing header file issue
in Makefile, any idea to solve this problem?

- Joey

On Tue, Sep 16, 2014 at 2:18 AM, Andrew MacLeod  wrote:
> During the re-architecture session at Cauldron, I mentioned the possibility
> of introducing a plugin-headers.h.
>
> This would be a file which plugins could use which would protect them
> somewhat from header file restructuring.  The idea is that it includes all
> the common things plugins need, (like gimple.h, rtl.h, most-of-the-world.h,
> etc etc),.  When header files are restructured, that file would also be
> adjusted so that the correct include order is still maintained.  This could
> also give plugins a little more stability across releases since header files
> do come and go..
>
>  I am about to start another round of flattening and shuffling, so figured
> this might be a good time to introduce it.  Any of you plugin users have a
> list of includes you want to see in it, or better yet, provide me with a
> plugin-headers.h? ( Out of curiosity, is there a reason gcc-plugins.h
> doesn't include a pile of these common things?  or is that simply to avoid
> bringing in the world?) Or would you rather just continue to deal with the
> pain of header file name changing/content shuffling?  or is there a
> different solution proposal?
>
>
>  Andrew

Re: More useful support for low-end ARM architecture

[Joey Ye]

Markus,

-mmcu probably will not work for ARM architectured MCUs. Reason are
* Confusion. -mcpu is encouraged and already widely used for ARM
architectures. Introducing -mmcu will be very confusing.
* Expensive effort. Either supporting none, or supporting all. There
are large number of MCUs from ARM eco-system partners. Supporting all
of them is a large project.
* Maintance nightmare. Having GCC developers to input and maintain
vendor specific configurations is inefficient and error-prone.
* Failed schedule dependence. Having -mmcu actually means whenever
there is a new MCU introduced into market, GCC has to be updated to
describe it. Given GCC's release cycle (once per year) and the
frequency of MCU release (could be tens each year), GCC will never be
able to catch up.

Further more all the board/MCU specific configurations are already
described in CMSIS and variant of GUI based toolchain for ARM MCU.
Replicating then in GCC does not sounds a right thing to do for me.

From the link you shared I also noticed some other discussion
regarding makefile, libraries and other options, which are very
interesting but off scope of GCC mail list. Shall we please continue
the discuss at https://answers.launchpad.net/gcc-arm-embedded/+question/257326
?

Thanks,
Joey

On Sun, Nov 9, 2014 at 3:42 AM, Markus Hitter  wrote:
> Hello gcc folks,
>
> recently I started to expand a project of mine running mainly on AVR ATmega 
> to low end ARM chips. To my enlightment, gcc supports these thingies already. 
> To my disappointment, this support is pretty complicated. One faces at least 
> a much steeper learning curve that on AVR. Accordingly I suggested on the 
> avr-libc mailing list to do similar work for ARM, Cortex-M0 to Cortex-M4. At 
> least four people expressed interest, it looks like arm-libc is about to be 
> born.
>
> To those not knowing what this is, I talk here about all-in-one CPUs (MCUs) 
> with memory and some peripherals already on the chip. Program memory can be 
> as low as 8 kB, RAM as low as 1 kB. Usually they're programmed bare-metal, 
> this is, without any operating system.
>
> If you want to take a look at a simple Hello World application, here is one:
>
> https://bugs.launchpad.net/gcc-arm-embedded/+bug/1387906
>
> Looking at its Makefile, it requires quite a number of flags, among them nine 
> -I with custom paths, --specs, -T and also auto-generated C files. Lots of 
> stuff average programmers probably don't even know it exists. One of the 
> interested persons on the avr-libc mailing list explained what's missing, 
> much better than I could:
>
>> I think what the other responders missed is that avr-libc (via its
>> integration with binutils and gcc) gives you two key pieces of
>> functionality:
>>
>> -mmcu=atmega88
>> #include 
>>
>> You *also* get classic libc functionality (printf, etc) that's provided
>> on ARM by newlib etc, but that's not the big deal IMO.
>>
>> The #include is *relatively* easy, [... no topic for gcc ...]
>>
>> The -mmcu= functionality is even more deeply useful, although less
>> easily repeatable on ARM. It brings in the relevant linker script,
>> startup code, vector tables, and all the other infrastructure. *THAT*
>> is what makes it possible to write a program like:
>>
>> #include 
>> int main() {
>>   DDRD = 0x01;PORTD = 0x01;
>> }
>>
>> # avr-gcc -mmcu=atmega88 -o test test.c
>> # avrdude
>>
>> Writing a program for your random ARM chip requires digging *deeply*
>> into the various websites or IDEs of the manufacturer, trying to find
>> the right files (the filenames alone of which vary in strange ways),
>> probably determining the right way to alter them because the only
>> example you found was for a different chip in the same line, and then
>> hoping you've got everything glued together properly.
>>
>> I want to be able to write the above program (modified for the right
>> GPIO) and run:
>>
>> # arm-none-eabi-gcc -mmcu=stm32f405 -o test test.c
>
> This is why I joined here, we'd like to get -mmcu for all the ARM flavours. 
> It should pick up a linker script which works in most cases on its own. It 
> should also bring in startup code, so code writers don't have to mess with 
> stuff happening before main(). And not to forget, pre-set #defines like 
> __ARM_LPC1114__, __ARM_STM32F405__, etc.
>
> - How would we proceed in general?
>
> - Many flavours at once, or better start with one or two, adding more when 
> these work?
>
> - Did AVR support make things we should not repeat?
>
>
> Thanks for discussing,
>
> Markus
>
> P.S.: arm-libc discussion so far can be followed here:
> http://lists.nongnu.org/archive/html/avr-libc-dev/2014-11/threads.html
>
> --
> - - - - - - - - - - - - - - - - - - -
> Dipl. Ing. (FH) Markus Hitter
> http://www.jump-ing.de/

Re: More useful support for low-end ARM architecture

[Joey Ye]

On Wed, Nov 12, 2014 at 1:47 AM, Joern Rennecke
 wrote:
> On 11 November 2014 16:22, Joey Ye  wrote:
>> * Expensive effort. Either supporting none, or supporting all. There
>> are large number of MCUs from ARM eco-system partners. Supporting all
>> of them is a large project.
>> * Maintance nightmare. Having GCC developers to input and maintain
>> vendor specific configurations is inefficient and error-prone.
>> * Failed schedule dependence. Having -mmcu actually means whenever
>> there is a new MCU introduced into market, GCC has to be updated to
>> describe it. Given GCC's release cycle (once per year) and the
>> frequency of MCU release (could be tens each year), GCC will never be
>> able to catch up.
>
> These kinds of issues were why I re-implemented the avr -mmcu option
> with the SELF_SPEC mechanism to read a device-specific spec file.
>
> As long as a new mcu can be described with the existing toolchain facilities
> (e.g. a new combination of existing I/O support, some different parameters
>  describing RAM / flash sizes), a new spec file can be distributed together
> with a few hardware-specific library/crt files to support a new mcu with
> an existing compiler.
Indeed. Took a look at the patch and I have to say it is a quite smart idea.

>
>> Further more all the board/MCU specific configurations are already
>> described in CMSIS and variant of GUI based toolchain for ARM MCU.
>> Replicating then in GCC does not sounds a right thing to do for me.
>
> Yes, better to have a script that translates this info into a suitable spec 
> file
> and copies any required files in the appropriate installation places.
> Not sure what kind of Copyright/licensing issues that would entail, though
I would think of a separate project, where people can add new NCU
configuration there independent to GCC.

Thanks,
Joey

Re: ldm/stm bus error

[Joey Ye]

In this case ldm is loading at alignment address. It is just loaded
more than sizeof a. So it can be the bus that does not permit
accessing memory beyond address range of a. Such a case I don't
believe compiler is doing wrong.

On Mon, May 18, 2015 at 4:50 PM, Richard Earnshaw
 wrote:
> On 18/05/15 10:05, Umesh Kalappa wrote:
>> Hi All,
>>
>> Getting a bus/hard error for the below case ,make sense since ldm/stm
>> expects the address to be word aligned .
>>
>> bash-4.1$ cat test.c
>> struct test
>> {
>> char c;
>> int i;
>> } __attribute__((packed));
>>
>> struct test a,b;
>>
>> int main()
>> {
>> a =b ; //here compiler is not sure that a or b is word aligned
>> return a.i;
>> }
>>
>> bash-4.1$ arm-eabi-gcc -v
>> Using built-in specs.
>> COLLECT_GCC=arm-eabi-gcc
>> COLLECT_LTO_WRAPPER=/nobackup/ukalappa/build/gcc/mv-ga/c4.7.0-p1/x86_64-linux/libexec/gcc/arm-eabi/4.7.0/lto-wrapper
>> Target: arm-eabi
>> Configured with: /nobackup/ukalappa/src/gcc/mv-ga/gcc/configure
>> --srcdir=/nobackup/ukalappa/src/gcc/mv-ga/gcc --build=x86_64-linux
>> --target=arm-eabi --host=x86_64-linux
>> --prefix=/nobackup/ukalappa/build/gcc/mv-ga/c4.7.0-p1
>> --exec-prefix=/nobackup/ukalappa/build/gcc/mv-ga/c4.7.0-p1/x86_64-linux
>> --with-pkgversion='Cisco GCC c4.7.0-p1' --with-cisco-patch-level=1
>> --with-cisco-patch-level-minor=0
>> --with-bugurl=http://wwwin.cisco.com/it/services/
>> --disable-maintainer-mode --enable-languages=c,c++ --disable-nls
>> Thread model: single
>> gcc version 4.7.0
>>
>> bash-4.1$ ./arm-eabi-gcc -march=armv7 -mthumb  -S test.c
>>
>> bash-4.1$ cat test.s
>> .syntax unified
>> .arch armv7
>> .fpu softvfp
>> .eabi_attribute 20, 1
>> .eabi_attribute 21, 1
>> .eabi_attribute 23, 3
>> .eabi_attribute 24, 1
>> .eabi_attribute 25, 1
>> .eabi_attribute 26, 1
>> .eabi_attribute 30, 6
>> .eabi_attribute 34, 1
>> .eabi_attribute 18, 4
>> .thumb
>> .file   "test.c"
>> .comm   a,5,4
>> .comm   b,5,4
>
> The above two lines create (common) instances of a and b that are 4-byte
> aligned, so the LDM should not be faulting in this case, unless your
> binutils have ignored the alignment constraints.
>
> I don't think the compiler has done the wrong thing here.
>
> R.
>
>> .text
>> .align  2
>> .global main
>> .thumb
>> .thumb_func
>> .type   main, %function
>> main:
>> @ args = 0, pretend = 0, frame = 0
>> @ frame_needed = 1, uses_anonymous_args = 0
>> @ link register save eliminated.
>> push{r7}
>> add r7, sp, #0
>> movwr3, #:lower16:a
>> movtr3, #:upper16:a
>> movwr2, #:lower16:b
>> movtr2, #:upper16:b
>> ldmia   r2, {r0, r1}   //Bus error
>> str r0, [r3]
>> addsr3, r3, #4
>> strbr1, [r3]
>> movwr3, #:lower16:a
>> movtr3, #:upper16:a
>> ldr r3, [r3, #1]@ unaligned
>> mov r0, r3
>> mov sp, r7
>> pop {r7}
>> bx  lr
>> .size   main, .-main
>>
>>
>> Arm states that ldm/stm should be word aligned and generating ldm/stm
>> in the above case is the compiler error/bug ,do you guys agree with me
>> or i'm missing something here ?
>>
>>
>> Thank you
>> ~Umesh
>>
>

Continue strict-volatile-bitfields fixes

[Joey Ye]

-fstrict-volatile-bitfields doesn't work incorrectly in some cases 
when storing into a volatile bit-field. 

Bernd provided a fix here about 1 year ago:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00217.html.
But it is pending to trunk. Here are my humble opinions and hopefully 
we can revive it:

1. The fix could have helped lots of those who use volatile bit-fields, 
but has been blocked for 1 year by ABI version 1, a feature that I believe 
no one nowadays is using with latest gcc. Either error out ABI version 1
for some target, or just revising the failed ABI test case is OK for me.

2. This bug impacts all targets, especially target with 
strict-volatile-bitfields default enabled like ARM. The test case Bernd 
provided can be revised to a target independent case.

+++ gcc/testsuite/gcc.dg/volatile-bitfields-4.c (revision 0)
@@ -0,0 +1,15 @@ 
+/* { dg-do run } */
+/* { dg-options "-fstrict-volatile-bitfields" } */
+
+extern void abort(void);
+struct thing {
+  volatile unsigned short a: 8;
+  volatile unsigned short b: 8;
+} t = {1,2};
+
+int main()
+{
+  t.a = 3;
+  if (t.a !=3 || t.b !=2) abort();
+  return 0;
+}

Re: ARM: VFPv3-D16 vs. VFPv3-D32

[Joey Ye]

Which Cortex-R you are targeting that supports both D16 and D32?

Thanks,
Joey

On Thu, Oct 17, 2013 at 3:13 PM, Sebastian Huber
 wrote:
> Hello,
>
> it seems that it is not possible to deduce from GCC built-in defines whether
> we compile for the VFPv3-D16 or VFPv3-D32 floating point unit.
>
> touch empty.c
>
> arm-eabi-gcc -march=armv7-r -mfpu=vfpv3-d16 -mfloat-abi=hard -E -P -v -dD
> empty.c > vfpv3-d16.txt
>
> arm-eabi-gcc -march=armv7-r -mfpu=vfpv3 -mfloat-abi=hard -E -P -v -dD
> empty.c > vfpv3-d32.txt
>
> diff vfpv3-d16.txt vfpv3-d32.txt
>
> Is it possible to add a built-in define for this?  Or as an alternative is
> it possible to use a GCC configuration target specific multi-lib define that
> indicates it?
>
> I want to use such a compiler provided define to determine how the context
> switch support in an operating system should look like.
>
> --
> 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.

Re: ARM: VFPv3-D16 vs. VFPv3-D32

[Joey Ye]

There is no macro to indicate VFP variances. Probably you can check
CPU variance instead. As I know Cortex-R only support D16.

Joey

On Thu, Oct 17, 2013 at 3:47 PM, Sebastian Huber
 wrote:
> On 2013-10-17 09:28, Joey Ye wrote:
>>
>> Which Cortex-R you are targeting that supports both D16 and D32?
>
>
> I have a Cortex-R variant which supports D16 only and now I want to add a
> multi-lib to our GCC target configuration and use a compiler built-in to
> adjust the context switch code for this multi-lib.
>
>
> --
> 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.

Still fails with strict-volatile-bitfields

[Joey Ye]

Sandra, Bernd,

Can you take a look at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734

It seems a siimple case still doesn't work as expected. Did I miss anything?

Thanks,
Joey

Re: Still fails with strict-volatile-bitfields

[Joey Ye]

Bernd,

If that's the case, can you please firstly fix invoke.texi where the
behavior of strict-volatile-bitfields is described? At least my
interpretation of current doc doesn't explain the behavior of the case
we are discussing. Also it should be a generic definition rather than
target specific one.

A related issue is that how would we expect users to build their
original code with volatile bitfields usage? From the approach I
understand they have to explicitly add -fstrict-volatile-bitfields for
4.9 (by default it is disabled now), and probably
-fstrict-volatile-bitfields=aapcs (to allow C++ memory model conflict)
later. Neither of them are obvious to users. How about a configure
option to set default?

Thanks,
Joey

On Fri, Jan 10, 2014 at 10:20 PM, Bernd Edlinger
 wrote:
> On Fri, 10 Jan 2014 14:45:12, Richard Biener wrote:
>>
>> On Fri, Jan 10, 2014 at 2:30 PM, Bernd Edlinger
>>  wrote:
>>> On, Fri, 10 Jan 2014 09:41:06, Richard Earnshaw wrote:

 On 10/01/14 08:49, Bernd Edlinger wrote:
> On Thu, 9 Jan 2014 16:22:33, Richard Earnshaw wrote:
>>
>> On 09/01/14 08:26, Bernd Edlinger wrote:
>>> Hi,
>>>
>>> On Thu, 9 Jan 2014 15:01:54, Yoey Ye wrote:

 Sandra, Bernd,

 Can you take a look at
 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734

 It seems a siimple case still doesn't work as expected. Did I miss 
 anything?

 Thanks,
 Joey
>>>
>>> Yes,
>>>
>>> this is a major case where the C++ memory model is
>>> in conflict with AAPCS.
>>>
>>
>> Does the compiler warn about this? And if so, is the warning on by
>> default? I think it's essential that we don't have quiet changes in
>> behaviour without such warnings.
>>
>> R.
>
> No. This example was working in 4.6 and broken in 4.7 and 4.8.
> Well, 4.7 should have warned about that.
>
> 4.9 does simply not change that, because it would violate the C++
> memory model. Maybe that should go into release notes.

 That's no excuse for not generating a warning at compile time when the
 situation is encountered. Users of this feature are experiencing a
 quiet change of behaviour and that's unacceptable, even if the compiler
 is doing what it was intended to do; that doesn't necessarily match the
 user's expectations. There should always be a way to rewrite the C11
 intended semantics in a way that doesn't violate the strict volatile
 bitfields semantics.

>>>
>>> Hmm...
>>> You mean we should have a (ugly) warning enabled by default in 4.9 (at 
>>> expmed.c)
>>> if a bit-field access would be perfectly aligned and so, but is in conflict 
>>> with the
>>> C++ memory model, and -fstrict-volatile-bitfields is in effect.
>>> Maybe only once per compilation?
>>
>> I'd say you want a warning for the structure declaration instead
>> "Accesses to XYZ will not follow AACPS due to C++ memory model
>> constraints".
>>
>> Richard.
>>
>
> Yes, that would be the way how we wanted to implement the
> -Wportable-volatility warning, except that it would be on by default
> if -fstrict-volatile-bitfields is in effect.
> And it would not only warn if the member is declared volatile,
> because the structure can be declared volatile later.
>
> Except that I did not even start to implement it that way, that
> would be quite late for 4.9 now?
>
> Bernd.
>>>
>
> At the same time we had all kinds of invalid code generation,
> starting at 4.6, especially with packed structures in C and Ada(!),
> (writing not all bits, and using unaligned accesses)
> and that is fixed in 4.9.
>

 I'm not worried about packed structures. You can't sensibly implement
 the strict volatile bitfields rules when things aren't aligned.

 R.

>
> Bernd.
>
>>
>>> You can get the expected code, by changing the struct
>>> like this:
>>>
>>> struct str {
>>> volatile unsigned f1: 8;
>>> unsigned dummy:24;
>>> };
>>>
>>> If it is written this way the C++ memory model allows
>>> QImode, HImode, SImode. And -fstrict-volatile-bitfields
>>> demands SImode, so the conflict is resolved. This dummy
>>> member makes only a difference on the C level, and is
>>> completely invisible in the generated code.
>>>
>>> If -fstrict-volatile-bitfields is now given, we use SImode,
>>> if -fno-strict-volatile-bitfields is given, we give GCC the
>>> freedom to choose the access mode, maybe QImode if that is
>>> faster.
>>>
>>> In the _very_ difficult process to find an solution
>>> that seems to be acceptable to all maintainers, we came to
>>> the solution, that we need to adhere to the C++ memory
>>> model by default. And we may not change the default
>>> setting of -fstruct-volatile-bitfields at the same time!
>>>
>>> As a future extension we discuss

Stack layout change during lra

[Joey Ye]

Vlad,

When fixing PR60169, I found that reload fail to assert
verify_initial_elim_offsets ()
  if (insns_need_reload != 0 || something_needs_elimination
  || something_needs_operands_changed)
{
  HOST_WIDE_INT old_frame_size = get_frame_size ();

  reload_as_needed (global);

  gcc_assert (old_frame_size == get_frame_size ());

  gcc_assert (verify_initial_elim_offsets ());
}

The reason is that stack layout changes during reload_as_needed as a result
of a thumb1 backend heuristic.

I have a patch to make sure the heuristic doesn't change stack layout during
and after reload, and the assertion disappeared. However, I'm not sure if it
will also be a problem in lra. Here is the question more specific:

Is that any chance during lra_in_progress that: stack layout can no longer
be altered, but insns can still be added or changed?

Thanks,
Joey

Fragile test case nsdmi-union5.C

[Joey Ye]

Ran into a fragile test case:
FAIL: g+.dg/cpp0x/nsdmi-union5.C -std=c+11 scan-assembler 7

$ cat nsdmi-union5.C
// PR c++/58701
// { dg-require-effective-target c++11 }
// { dg-final { scan-assembler "7" } }

static union
{
  union
  {
int i = 7;
  };
};

Two issues make it very fragile. It only seems to pass with -O0, as the code
will be optimized away with any non-O0 levels. This is somewhat acceptable,
but following is annoying: It scans digit 7 in resulting asm, which will
pass whenever 
* Any CPU name, file name, svn/git revision number and ARM eabi_attribute
contain digit 7. 
* All GCC x.7 versions
* Any GCC built in July or on 7th/17th/27th of the month, or in 2017
Actually I ran into this issue when I checked my test result with a
reference. Unfortunately one has digit 7 in revision number and one has not.

I tend to just not scan anything and makes it a do-compile case against ICE.
But I'm not sure if there was a reason to scan the digit. Please comment.

Thanks,
Joey

ICE when calculate insn latency for armv7e-m arch in O2 level

[Joey Ye]

Greta,

Since this checkin, GCC ICE when build fix-point library with
-march=armv7e-m -O2. Reduced test case at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53859

This is a show-stopper to cortex-m4 target.


URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188742
Log:
The main function for epilogue RTL generation, used by expand epilogue
patterns.

gcc/

2012-06-18  Ian Bolton  
Sameera Deshpande  
Greta Yorsh  

* config/arm/arm-protos.h (arm_expand_epilogue): New declaration.
* config/arm/arm.c (arm_expand_epilogue): New function.
* config/arm/arm.md (epilogue): Update condition and code.
(sibcall_epilogue): Likewise.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.md

regsiter_tm_clones in crtbegin.o

[Joey Ye]

Since 4.7 register_tm_clones and deregister_tm_clones are added in
crtbegin.o. Built for ARM they eat 80 precious bytes of flash for each
application. They seem to be for transaction memory only and my build
doesn't need it.

I can simple disable them by -DUSE_TM_CLONE_REGISTERY=0 in a tmake_file. But
I'm not sure if I should put it just under config/arm, or make it more
general under config.

Anybody else share same problem?

Thanks - Joey

RE: [RFC] Unsolicited usage of VFP registers for Cortex-M4F

[Joey Ye]

> -Original Message-
> From: Ilija Kocho [mailto:ili...@siva.com.mk]
> Sent: Tuesday, October 09, 2012 21:08
> To: Joey Ye
> Cc: gcc@gcc.gnu.org; Terry Guo
> Subject: Re: [RFC] Unsolicited usage of VFP registers for Cortex-M4F
> 
> Hi Joey
> 
> Thank you for explanations. Now I have some comments and additional
> questions. Since now it will be a discussion rather than looking for
> help, I am re-routing the discussion to GCC mailing list. For those
> looking for the complete history, here is the context:
> http://gcc.gnu.org/ml/gcc-help/2012-10/msg00055.html
> 
> 
> On 09.10.2012 12:21, Joey Ye wrote:
> 
> [snip]
> 
> >> On 24.09.2012 12:30, Ilija Kocho wrote:
> >>> Hi colleagues
> >>>
> >>> In a course of implementing lazy context switching I the following
> >>> link come to me:
> >>>
> >>>
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0298a/DA
> >>> FIFGGE.html
> >>>
> [snip]
> >>> Therefore here are my questions:
> >>>
> >>> 1) Does GCC use VFP registers for holding data other than floating
> >>> point values (unsolicited VFP usage)?
> > It doesn't so far. Although GCC has no problem use FP for non-FP, the
> cost
> > model in ARM backend says using VFP isn't performing better than
> otherwise.
> >
> > For Cortex-M4F this isn't the best approach. I worked out a patch to
> tune
> > the cost model for M4F together with an option to enable/disable it.
> I'm
> > hoping to submit it later this year and it should enable Cortex-M4F
> to use
> > VFP extensively for non-FP data when option enabled.
> >
> >>> If (1) is true:
> >>> 1.1) What conditions, in addition to selecting -mfloat-abi=hard (or
> >>> softfp) shall cause such behaviour. I would appreciate some test
> case.
> > When the patch is upstreamed, and given that -ffpreg-for-nonfpdata is
> > provided, VFP will be used for non-FP data when ever register
> pressure is
> > high.
> >
> [snip]
> >> 1.4) Can it be disabled? I found no such command line option for ARM
> >> targets.
> > The command line will be as -f[no-]fpreg-for-nonfpdata
> 
> According to current GCC conventions shoulfn't it begin with "m" i.e.
> -m[no]fpreg-for-nonfpdata ?
My typo. Should be -m.

> 
> >>> 2) Above quote states that -mfloat-abi=soft should be used for libs,
> but
> >>> ld refuses to link them with code produced with -mfloat-abi=hard
> even if
> >>> the libs do not use floating point operations. Is there a waay to
> tweak this?
> > The quote isn't accurate nowadays. More and more libraries are built
> with
> > hard. Also a mechanism called multilib enables you to pick soft or
> hard
> > automatically according to linker command line
> 
> Although I am not GCC expert I am aware of multilibs. Indeed, I have
> succeeded in building of GCC with a pretty rich multilib collection.
> 
> But my point is: at present, due to floating point ABI incompatibility,
> we can't link functions/libs compiled with -mfloat-abi=soft flag to
> functions/libs compiled with -mfloat-abi=hard flag, regardless whether
> floating point is effectively in use or not.
> But, won't particular functions, that _do not_ use floating point,
> effectively have same ABI regardless of flags used (-mfloat-abi=soft or
> -mfloat-abi=hard)? Then shouldn't it be possible to link them to both
> /soft/ and /hard/ float-abi code?
Then linker need to detect if there is really _no_ FP usage in a /hard/
copy, which is difficult if not impossible.

The whole idea of different float ABI is to avoid such kind of check or the
quiet runtime error without appropriate check. No matter what motivation
behinds, I won't try to interlink soft and hard from maintain-ability and
stability point of view.

> 
> Any comments?
> 
> Ilija
>