Re: Bit-field struct member sign extension pattern results in redundant

[Gabriel Paubert]

On Fri, Aug 18, 2017 at 10:29:04AM +1200, Michael Clark wrote:
> Sorry I had to send again as my Apple mailer is munging emails. I’ve disabled 
> RTF.
> 
> 
> This one is quite interesting:
> 
> - https://cx.rv8.io/g/WXWMTG
> 
> It’s another target independent bug. x86 is using some LEA followed by SAR 
> trick with a 3 bit shift. Surely SHL 27, SAR 27 would suffice. In any case 
> RISC-V seems like a nice target to try to fix this codegen for, as its less 
> risk than attempting a fix in x86 ;-)
> 
> - https://github.com/riscv/riscv-gcc/issues/89
> 
> code:
> 
>   template 
>   inline T signextend(const T x)
>   {
>   struct {T x:B;} s;
>   return s.x = x;
>   }
> 
>   int sx5(int x) {
>   return signextend(x);
>   }
> 
> riscv asm:
> 
>   sx5(int):
> slliw a0,a0,3
> slliw a0,a0,24
> sraiw a0,a0,24
> sraiw a0,a0,3
> ret
> 
> hand coded riscv asm
> 
>   sx5(int):
> slliw a0,a0,27
> sraiw a0,a0,27
> ret
> 
> x86 asm:
> 
>   sx5(int):
> lea eax, [0+rdi*8]
> sar al, 3
> movsx eax, al
> ret
> 
> hand coded x86 asm (no worse because the sar depends on the lea)
> 
>   sx5(int):
> shl edi, 27
> sar edi, 27
> movsx eax, dl

Huh? dl is not a subreg of edi!

s/edi/edx/ and it may work.

dil can also be used, but only on 64 bit.

Gabriel

Re: Bit-field struct member sign extension pattern results in redundant

[Michael Clark]

> On 18 Aug 2017, at 10:41 PM, Gabriel Paubert  wrote:
> 
> On Fri, Aug 18, 2017 at 10:29:04AM +1200, Michael Clark wrote:
>> Sorry I had to send again as my Apple mailer is munging emails. I’ve 
>> disabled RTF.
>> 
>> 
>> This one is quite interesting:
>> 
>> - https://cx.rv8.io/g/WXWMTG
>> 
>> It’s another target independent bug. x86 is using some LEA followed by SAR 
>> trick with a 3 bit shift. Surely SHL 27, SAR 27 would suffice. In any case 
>> RISC-V seems like a nice target to try to fix this codegen for, as its less 
>> risk than attempting a fix in x86 ;-)
>> 
>> - https://github.com/riscv/riscv-gcc/issues/89
>> 
>> code:
>> 
>>  template 
>>  inline T signextend(const T x)
>>  {
>>  struct {T x:B;} s;
>>  return s.x = x;
>>  }
>> 
>>  int sx5(int x) {
>>  return signextend(x);
>>  }
>> 
>> riscv asm:
>> 
>>  sx5(int):
>>slliw a0,a0,3
>>slliw a0,a0,24
>>sraiw a0,a0,24
>>sraiw a0,a0,3
>>ret
>> 
>> hand coded riscv asm
>> 
>>  sx5(int):
>>slliw a0,a0,27
>>sraiw a0,a0,27
>>ret
>> 
>> x86 asm:
>> 
>>  sx5(int):
>>lea eax, [0+rdi*8]
>>sar al, 3
>>movsx eax, al
>>ret
>> 
>> hand coded x86 asm (no worse because the sar depends on the lea)
>> 
>>  sx5(int):
>>shl edi, 27
>>sar edi, 27
>>movsx eax, dl
> 
> Huh? dl is not a subreg of edi!
> 
> s/edi/edx/ and it may work.
> 
> dil can also be used, but only on 64 bit.

Sorry I meant dil on x86-64. I was sure that it was possible to extend into 
another register. I have not done much i386 asm so I am unaware of the 
constraints. Can the source and dest registers for movsx not differ on i386? I 
thought they could.

In any case, the plot thickens…

I believe we have bugs on both RISC-V and Aarch64.

I found that it at least appears like it is transitioning to a char or short as 
the break is at 24 and 16 depending on the width, and values over 16 work as 
one would expect.

Here is an updated test program: https://cx.rv8.io/g/M9ewNf

template 
inline T signextend(const T x)
{
  struct {T x:B;} s;
  return s.x = x;
}

int sx3(int x) { return signextend(x); }
int sx5(int x) { return signextend(x); }
int sx11(int x) { return signextend(x); }
int sx14(int x) { return signextend(x); }
int sx19(int x) { return signextend(x); }

I filed a bug on riscv-gcc but I think it is target independent code given 
there appears to be an issue on Aarch64. AFAICT, Aarch64 should generate a 
single sbfx for all of the test functions.

- https://github.com/riscv/riscv-gcc/issues/89

Should I file a bug on GCC bugzilla given it looks to be target independent?

On RISC-V, the codegen is much more obviously wrong, but essentially the same 
thing is happening on Aarch64 but there is only one additional instruction 
instead of two.

sx3(int):
  slliw a0,a0,5
  slliw a0,a0,24
  sraiw a0,a0,24
  sraiw a0,a0,5
  ret
sx5(int):
  slliw a0,a0,3
  slliw a0,a0,24
  sraiw a0,a0,24
  sraiw a0,a0,3
  ret
sx11(int):
  slliw a0,a0,5
  slliw a0,a0,16
  sraiw a0,a0,16
  sraiw a0,a0,5
  ret
sx14(int):
  slliw a0,a0,2
  slliw a0,a0,16
  sraiw a0,a0,16
  sraiw a0,a0,2
  ret
sx19(int):
  slliw a0,a0,13
  sraiw a0,a0,13
  ret

Re: Bit-field struct member sign extension pattern results in redundant

[Michael Clark]

> On 18 Aug 2017, at 10:56 PM, Michael Clark  wrote:
> 
>> 
>> On 18 Aug 2017, at 10:41 PM, Gabriel Paubert  wrote:
>> 
>> On Fri, Aug 18, 2017 at 10:29:04AM +1200, Michael Clark wrote:
>>> Sorry I had to send again as my Apple mailer is munging emails. I’ve 
>>> disabled RTF.
>>> 
>>> 
>>> This one is quite interesting:
>>> 
>>> - https://cx.rv8.io/g/WXWMTG
>>> 
>>> It’s another target independent bug. x86 is using some LEA followed by SAR 
>>> trick with a 3 bit shift. Surely SHL 27, SAR 27 would suffice. In any case 
>>> RISC-V seems like a nice target to try to fix this codegen for, as its less 
>>> risk than attempting a fix in x86 ;-)
>>> 
>>> - https://github.com/riscv/riscv-gcc/issues/89
>>> 
>>> code:
>>> 
>>> template 
>>> inline T signextend(const T x)
>>> {
>>> struct {T x:B;} s;
>>> return s.x = x;
>>> }
>>> 
>>> int sx5(int x) {
>>> return signextend(x);
>>> }
>>> 
>>> riscv asm:
>>> 
>>> sx5(int):
>>>   slliw a0,a0,3
>>>   slliw a0,a0,24
>>>   sraiw a0,a0,24
>>>   sraiw a0,a0,3
>>>   ret
>>> 
>>> hand coded riscv asm
>>> 
>>> sx5(int):
>>>   slliw a0,a0,27
>>>   sraiw a0,a0,27
>>>   ret
>>> 
>>> x86 asm:
>>> 
>>> sx5(int):
>>>   lea eax, [0+rdi*8]
>>>   sar al, 3
>>>   movsx eax, al
>>>   ret
>>> 
>>> hand coded x86 asm (no worse because the sar depends on the lea)
>>> 
>>> sx5(int):
>>>   shl edi, 27
>>>   sar edi, 27
>>>   movsx eax, dl
>> 
>> Huh? dl is not a subreg of edi!
>> 
>> s/edi/edx/ and it may work.
>> 
>> dil can also be used, but only on 64 bit.

In any case it is more straightforward given we are just dealing with an int 
bitfield member in this case so a regular move would suffice. The mov gets 
retired in rename (movsx and movzx can both be retired in rename I think). The 
same pattern could be used for all 5 function examples, with predictable 
performance, versus 5 different solutions for the 5 different bitfield 
positions (that’s actually very amazing that the pattern matching on x86 finds 
5 unique ways to lower this code pattern).  Padon my Intel syntax. e.g.

sx5(int):
 shl edi, 27
 sar edi, 27
 mov eax, edi

However I’m more interested in what the fix would be for RISC-V and Aarch64. 
It’s less obvious how to fix it on x86-64 because there are too many different 
ways. On RISC-V there is only one obvious way and that is to not artificially 
narrow the type when we are extracting from an int aligned struct bit field 
member to an int. Likewise on Aarch64, one sbfiz instruction.

> Sorry I meant dil on x86-64. I was sure that it was possible to extend into 
> another register. I have not done much i386 asm so I am unaware of the 
> constraints. Can the source and dest registers for movsx not differ on i386? 
> I thought they could.
> 
> In any case, the plot thickens…
> 
> I believe we have bugs on both RISC-V and Aarch64.
> 
> I found that it at least appears like it is transitioning to a char or short 
> as the break is at 24 and 16 depending on the width, and values over 16 work 
> as one would expect.
> 
> Here is an updated test program: https://cx.rv8.io/g/M9ewNf
> 
>   template 
>   inline T signextend(const T x)
>   {
> struct {T x:B;} s;
> return s.x = x;
>   }
> 
>   int sx3(int x) { return signextend(x); }
>   int sx5(int x) { return signextend(x); }
>   int sx11(int x) { return signextend(x); }
>   int sx14(int x) { return signextend(x); }
>   int sx19(int x) { return signextend(x); }
> 
> I filed a bug on riscv-gcc but I think it is target independent code given 
> there appears to be an issue on Aarch64. AFAICT, Aarch64 should generate a 
> single sbfx for all of the test functions.
> 
> - https://github.com/riscv/riscv-gcc/issues/89
> 
> Should I file a bug on GCC bugzilla given it looks to be target independent?
> 
> On RISC-V, the codegen is much more obviously wrong, but essentially the same 
> thing is happening on Aarch64 but there is only one additional instruction 
> instead of two.
> 
>   sx3(int):
> slliw a0,a0,5
> slliw a0,a0,24
> sraiw a0,a0,24
> sraiw a0,a0,5
> ret
>   sx5(int):
> slliw a0,a0,3
> slliw a0,a0,24
> sraiw a0,a0,24
> sraiw a0,a0,3
> ret
>   sx11(int):
> slliw a0,a0,5
> slliw a0,a0,16
> sraiw a0,a0,16
> sraiw a0,a0,5
> ret
>   sx14(int):
> slliw a0,a0,2
> slliw a0,a0,16
> sraiw a0,a0,16
> sraiw a0,a0,2
> ret
>   sx19(int):
> slliw a0,a0,13
> sraiw a0,a0,13
> ret

[OT] Re: Bit-field struct member sign extension pattern results in redundant

[Gabriel Paubert]

On Fri, Aug 18, 2017 at 10:56:10PM +1200, Michael Clark wrote:
> 
> > On 18 Aug 2017, at 10:41 PM, Gabriel Paubert  wrote:
> > 
> > On Fri, Aug 18, 2017 at 10:29:04AM +1200, Michael Clark wrote:
> >> Sorry I had to send again as my Apple mailer is munging emails. I’ve 
> >> disabled RTF.
> >> 
> >> 
> >> This one is quite interesting:
> >> 
> >> - https://cx.rv8.io/g/WXWMTG
> >> 
> >> It’s another target independent bug. x86 is using some LEA followed by SAR 
> >> trick with a 3 bit shift. Surely SHL 27, SAR 27 would suffice. In any case 
> >> RISC-V seems like a nice target to try to fix this codegen for, as its 
> >> less risk than attempting a fix in x86 ;-)
> >> 
> >> - https://github.com/riscv/riscv-gcc/issues/89
> >> 
> >> code:
> >> 
> >>template 
> >>inline T signextend(const T x)
> >>{
> >>struct {T x:B;} s;
> >>return s.x = x;
> >>}
> >> 
> >>int sx5(int x) {
> >>return signextend(x);
> >>}
> >> 
> >> riscv asm:
> >> 
> >>sx5(int):
> >>  slliw a0,a0,3
> >>  slliw a0,a0,24
> >>  sraiw a0,a0,24
> >>  sraiw a0,a0,3
> >>  ret
> >> 
> >> hand coded riscv asm
> >> 
> >>sx5(int):
> >>  slliw a0,a0,27
> >>  sraiw a0,a0,27
> >>  ret
> >> 
> >> x86 asm:
> >> 
> >>sx5(int):
> >>  lea eax, [0+rdi*8]
> >>  sar al, 3
> >>  movsx eax, al
> >>  ret
> >> 
> >> hand coded x86 asm (no worse because the sar depends on the lea)
> >> 
> >>sx5(int):
> >>  shl edi, 27
> >>  sar edi, 27
> >>  movsx eax, dl
> > 
> > Huh? dl is not a subreg of edi!
> > 
> > s/edi/edx/ and it may work.
> > 
> > dil can also be used, but only on 64 bit.
> 
> Sorry I meant dil on x86-64. I was sure that it was possible to extend into 
> another register. 

It is, but only from the first 4 registers on 32 bit: AL, BL, CL, and
DL can be accessed as 8 bit registers, as well as the high part of the
16 bit registers: AH, BH, CH and DH.

This is essentially a left-over of the 16 bit processors (8086 to
80286), carried over without change in the 32 bit processors.

64 bit extensions made registers more orthogonal in this respect, but
there is still some weirdness due to historical reasons.

> I have not done much i386 asm so I am unaware of the constraints. 

Fortunate you are, especially since you hopefully did not have to live
through the 16 bit nightmare of segments and near and far addresses.

>Can the source and dest registers for movsx not differ on i386? I thought they 
>could.

They can, but only from the first 4 registers. On the other hand
movsx eax,dh (in Intel's syntax) is perfectly valid.

> In any case, the plot thickens…
> 
> I believe we have bugs on both RISC-V and Aarch64.

Maybe, I don't know either arch well enough, but RISC-V looks intuitive
enough to understand that it is bad both in terms of performance and
code size.

Another arch you could try is Power.

> I found that it at least appears like it is transitioning to a char or short 
> as the break is at 24 and 16 depending on the width, and values over 16 work 
> as one would expect.
> 
> Here is an updated test program: https://cx.rv8.io/g/M9ewNf
> 
>   template 
>   inline T signextend(const T x)
>   {
> struct {T x:B;} s;
> return s.x = x;
>   }
> 
>   int sx3(int x) { return signextend(x); }
>   int sx5(int x) { return signextend(x); }
>   int sx11(int x) { return signextend(x); }
>   int sx14(int x) { return signextend(x); }
>   int sx19(int x) { return signextend(x); }
> 
> I filed a bug on riscv-gcc but I think it is target independent code given 
> there appears to be an issue on Aarch64. AFAICT, Aarch64 should generate a 
> single sbfx for all of the test functions.
> 
> - https://github.com/riscv/riscv-gcc/issues/89
> 
> Should I file a bug on GCC bugzilla given it looks to be target independent?

I think so, but you should get confirmation from someone else.

> 
> On RISC-V, the codegen is much more obviously wrong, but essentially the same 
> thing is happening on Aarch64 but there is only one additional instruction 
> instead of two.
> 
>   sx3(int):
> slliw a0,a0,5
> slliw a0,a0,24
> sraiw a0,a0,24
> sraiw a0,a0,5
> ret
>   sx5(int):
> slliw a0,a0,3
> slliw a0,a0,24
> sraiw a0,a0,24
> sraiw a0,a0,3
> ret
>   sx11(int):
> slliw a0,a0,5
> slliw a0,a0,16
> sraiw a0,a0,16
> sraiw a0,a0,5
> ret
>   sx14(int):
> slliw a0,a0,2
> slliw a0,a0,16
> sraiw a0,a0,16
> sraiw a0,a0,2
> ret
>   sx19(int):
> slliw a0,a0,13
> sraiw a0,a0,13
> ret
> 
> 

Re: Bit-field struct member sign extension pattern results in redundant

[Oleg Endo]

On Fri, 2017-08-18 at 10:29 +1200, Michael Clark wrote:
> 
> This one is quite interesting:
> 
> - https://cx.rv8.io/g/WXWMTG
> 
> It’s another target independent bug. x86 is using some LEA followed
> by SAR trick with a 3 bit shift. Surely SHL 27, SAR 27 would suffice.
> In any case RISC-V seems like a nice target to try to fix this
> codegen for, as its less risk than attempting a fix in x86 ;-)
> 
> - https://github.com/riscv/riscv-gcc/issues/89
> 
> code:
> 
>   template 
>   inline T signextend(const T x)
>   {
>   struct {T x:B;} s;
>   return s.x = x;
>   }
> 
>   int sx5(int x) {
>   return signextend(x);
>   }
> 
> riscv asm:
> 
>   sx5(int):
>     slliw a0,a0,3
>     slliw a0,a0,24
>     sraiw a0,a0,24
>     sraiw a0,a0,3
>     ret
> 
> hand coded riscv asm
> 
>   sx5(int):
>     slliw a0,a0,27
>     sraiw a0,a0,27
>     ret
> 

Maybe related ...

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


Cheers,
Oleg

Re: Optimization breaks inline asm code w/ptrs

[Eric Gallager]

On 8/14/17, Alan Modra  wrote:
> On Sun, Aug 13, 2017 at 10:25:14PM +0930, Alan Modra wrote:
>> On Sun, Aug 13, 2017 at 03:35:15AM -0700, David Wohlferd wrote:
>> > Using "m"(*pStr) as an (unused) input parameter has no effect.
>>
>> Use "m" (*(const void *)pStr) and ignore the warning, or use
>> "m" (*(const struct {char a; char x[];} *) pStr).
>
> or even better "m" (*(const char (*)[]) pStr).
>
>> The issue is one of letting gcc know what memory is accessed by the
>> asm, if you don't want to use a "memory" clobber.  And there are very
>> good reasons to avoid clobbering all memory.
>>
>> "m"(*pStr) ought to work IMO, but apparently just tells gcc you are
>> only interested in the first character.  Of course that is exactly
>> what *pStr is, but in this context it would be nicer if it meant the
>> entire array.
>
> I take that back.  The relatively simple cast to differentiate a
> pointer to a char from a pointer to an indeterminate length char array
> makes it quite unnecessary for "m"(*pStr) to be treated as as array
> reference.
>
> I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to
> track the lack of documentation.
>

Alan, you might want to re-file that bug; it got lost in the Bugzilla
crash, and a different unrelated bug ended up taking its bug number...
(check the gcc-bugs archives)

> --
> Alan Modra
> Australia Development Lab, IBM
>

Re: Bit-field struct member sign extension pattern results in redundant

[Richard Henderson]

On 08/17/2017 03:29 PM, Michael Clark wrote:
> hand coded x86 asm (no worse because the sar depends on the lea)
> 
>   sx5(int):
> shl edi, 27
> sar edi, 27
> movsx eax, dl

Typo in the register, but I know what you mean.  More interestingly, edi
already has the sign-extended value, so "mov eax, edi" sufficies (saving one
byte or perhaps allowing better register allocation).

That said, if anyone is tweaking x86-64 patterns on this, consider

sx5(int):
rorxeax, edi, 5
sar eax, 27

where the (newish) bmi2 rorx instruction allows the data to be moved into place
while rotating, avoiding the extra move entirely.


r~

Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers

[R0b0t1]

On Fri, Aug 18, 2017 at 1:09 AM, Freddie Chopin  wrote:
> On Thu, 2017-08-17 at 22:27 -0500, R0b0t1 wrote:
>> On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1  wrote:
>> > When compiling libssp, ssp.c, function __guard_setup:
>> > O_RDONLY is undeclared (ssp.c:93:34),
>> > ssize_t is an unknown type name (ssp.c:96:7), and
>> > size_t is an unknown type name (ssp.c:113:25).
>> >
>> > ../../src/gcc-7.2.0/configure --target=$TARGET --prefix=$PREFIX
>> > --with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard
>> > --with-mode=thumb --enable-multilib --enable-interwork
>> > --enable-languages=c,c++ --with-system-zlib --with-newlib
>> > --disable-shared --disable-nls --with-gnu-as --with-gnu-ld
>> >
>> > A bootstrap C compiler is generated properly when passing --
>> > without-headers.
>> >
>> > I can provide more details and command output. Recently I was able
>> > to
>> > get 6.3.0 as close to working with Newlib 2.5 as I can tell, so
>> > this
>> > is not extremely urgent. Unfortunately I may have other questions
>> > about earlier GCC versions.
>> >
>>
>> I attempted to reproduce my build of GCC 6.3 and it's no longer
>> working. Both builds on Kubuntu 17.04.
>>
>> I'm kind of lost. Should I be filing bugs?
>>
>> > Any suggestions related to generating cross toolchains,
>> > specifically
>> > generating a toolchain close to the one found at
>> > https://developer.arm.com/open-source/gnu-toolchain/gnu-rm, would
>> > be
>> > extremely helpful. Any help provided will be used to better support
>> > for generating toolchains with the crossdev project.
>> >
>> > I am very confused and what I want to do seems to be poorly
>> > documented.
>> >
>> > Thanks in advance,
>> >  R0b0t1.
>
> Here you may find a complete script which builds the most recent
> versions of the toolchain for arm-none-eabi. If you browse git history
> you will also find a version for GCC 6.3.
>
> https://github.com/FreddieChopin/bleeding-edge-toolchain
>

On Fri, Aug 18, 2017 at 1:53 AM, Freddie Chopin  wrote:
> I forgot to say, that the procedure and resulting toolchain is closely
> modeled after the one provided by ARM on:
>
> https://developer.arm.com/open-source/gnu-toolchain/gnu-rm
>
> It just has couple of tweaks like slightly different options for
> newlib, completely disabled C++ exceptions and uses the most recent
> versions of components.
>

Thank you! I was able to use that script to produce a working
toolchain. I had successfully produced toolchains before, but the code
would not execute on device. Just to check, this is actually an
arm-none-eabi toolchain? I looked over the compilation flags and it
looks like it supports all Cortex-M processor features like such a
toolchain should. Most instructions I could find seemed to build a
more restricted toolchain.

I have looked at the supporting blog posts and read the documentation
available. I still do not understand why the specific binutils, gcc,
newlib, and gdb configurations were chosen, and why what is ostensibly
the same configuration failed when I tried it Would you please take
the time to document them, or point me towards a place that describes
what I should be looking for and why? I don't mind reading but I do
not know why the choices made are the correct ones and have been
unable to find anywhere that starts to offer any explanation.

I apologize for requesting that you donate your time, but if you feel
inclined you might want to look at the crossdev project. If I
eventually understand your script, or even if I don't, I may be able
to add better embedded target support (embedded targets are already
supported, but I receive build failures). Unfortunately the developers
of my distribution do not seem to have much of a hardware background
and people seem to expect me to contribute code. I am not smart enough
to do this, sir, and would appreciate whatever help you can offer to
this end.

Respectfully,
 R0b0t1

Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers

[Freddie Chopin]

On Fri, 2017-08-18 at 11:17 -0500, R0b0t1 wrote:
> Just to check, this is actually an
> arm-none-eabi toolchain? I looked over the compilation flags and it
> looks like it supports all Cortex-M processor features like such a
> toolchain should. Most instructions I could find seemed to build a
> more restricted toolchain.

The toolchain you get from this script supports - in case of GCC 7 -
following multilibs:

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

$ arm-none-eabi-gcc -print-multi-lib
.;
thumb;@mthumb
hard;@mfloat-abi=hard
thumb/v6-m;@mthumb@march=armv6s-m
thumb/v7-m;@mthumb@march=armv7-m
thumb/v7e-m;@mthumb@march=armv7e-m
thumb/v7-ar;@mthumb@march=armv7
thumb/v8-m.base;@mthumb@march=armv8-m.base
thumb/v8-m.main;@mthumb@march=armv8-m.main
thumb/v7e-m/fpv4-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv4-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv4-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5-sp/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5-sp/hard;@mthumb@march=armv7e-m@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v7e-m/fpv5/softfp;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v7e-m/fpv5/hard;@mthumb@march=armv7e-m@mfpu=fpv5-d16@mfloat-abi=hard
thumb/v7-ar/fpv3/softfp;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=softfp
thumb/v7-ar/fpv3/hard;@mthumb@march=armv7@mfpu=vfpv3-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5-sp/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5-sp/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-sp-d16@mfloat-abi=hard
thumb/v8-m.main/fpv5/softfp;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=softfp
thumb/v8-m.main/fpv5/hard;@mthumb@march=armv8-m.main@mfpu=fpv5-d16@mfloat-abi=hard

-- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 -- >8 --

That means you can use all ARM Cortex-M chips, with or without FPU, 32-
bit or 64-bit. You can also use ARM Cortex-R and "classic" ARM7TDMI.

This is the same set of architectures you get from the toolchain
provided by ARM.

> I have looked at the supporting blog posts and read the documentation
> available.

The blog post is really old and the part about performance is mostly
obsolte (;

> I still do not understand why the specific binutils, gcc,
> newlib, and gdb configurations were chosen, and why what is
> ostensibly
> the same configuration failed when I tried it Would you please take
> the time to document them, or point me towards a place that describes
> what I should be looking for and why? I don't mind reading but I do
> not know why the choices made are the correct ones and have been
> unable to find anywhere that starts to offer any explanation.

Generally I used the most recent components which are available for
download.

In the past - up to and including GCC 6 - the only exception were the
cases of supporting libraries (stuff like isl, mpfr, ...), where
_sometimes_ gcc docs say you must use a release from range x-y, not the
most recent one. In that case the most recent package from the range is
chosen. However the file gcc-7.2.0/gcc/doc/install.texi always says
"version x (or later)" so... I use the most recent one (; After all,
this is a "bleeding-edge" toolchain (;

Sometimes the version may be a bit older than the most recent one
either because I forgot to check, or because the most recent one has
some problems. This is the case for the most recent newlib snapshot
which fails to build for ARM - that's why I had to use a previous one.

Regards,
FCh

Re: Locating a commit from its ChangeLog entry (was Re: How to migrate ggc_alloc_XXX for GCC v8.x (git-20170816)?)

[Trevor Saunders]

Hi,

My first question would be why are you using the ChangeLog files at all?
It seems like it would be a lot more straight forward to just look at
blame for the thing that changed.

thanks

Trev

On Fri, Aug 18, 2017 at 09:32:34AM +0800, Leslie Zhai wrote:
> 
> 
> 在 2017年08月17日 23:10, David Malcolm 写道:
> > On Thu, 2017-08-17 at 09:52 +0800, Leslie Zhai wrote:
> > > Hi Trevor,
> > > 
> > > Thanks for your kind response!
> > > 
> > > 
> > > 在 2017年08月16日 20:02, Trevor Saunders 写道:
> > > > On Wed, Aug 16, 2017 at 05:32:10PM +0800, Leslie Zhai wrote:
> > > > > Hi GCC developers,
> > > > > 
> > > > > GCC v4.6's gengtype will auto-generate Allocators for known
> > > > > structs and
> > > > > unions, for example: ggc_alloc_tree2WeakVH for tree2WeakVH https:
> > > > > //github.com/xiangzhai/dragonegg/blob/master/include/dragonegg/gt
> > > > > -cache-4.6.inc#L24
> > > > > 
> > > > > but gengtype will not auto-generate ggc_alloc_XXX for GCC v6.x or
> > > > > v8.x
> > > > > (git-20170816), for example: struct GTY((for_user)) tree2WeakVH h
> > > > > ttps://github.com/xiangzhai/dragonegg/blob/master/include/dragone
> > > > > gg/gt-cache-8.0.inc#L1284
> > > > > 
> > > > > As ChangeLog-2014 mentioned:
> > > > > 
> > > > > 2014-05-17  Trevor Saunders 
> > > > > 
> > > > >   ...
> > > > >   (ggc_alloc): Install the type's destructor as the finalizer
> > > > > if it
> > > > >   might do something.
> > > > > 
> > > > > Please give me some hint about ggc_alloc migration, thanks a lot!
> > > > if you look at the patches they convert ggc_alloc_foo to
> > > > ggc_alloc
> > > > and you should do the same.
> > > Thanks for your hint! I do the same :)
> > > https://github.com/xiangzhai/dragonegg/blob/master/src/Cache.cpp#L255
> > > PS: how to find the relative patch for the ChangeLog's item? I use
> > > Google, for example: (ggc_alloc): Install the type's destructor as
> > > the
> > > finalizer if it might do something.
> > Another way is to use "git blame" on the ChangeLog to find the commit
> > that added the ChangeLog entry.
> > 
> > For "archived" ChangeLog files like "ChangeLog-2014" that will just
> > tell you which commit moved all of the entries for that years ChangeLog
> > entries to "ChangeLog-2014", so you can use "git log":
> > 
> >git log gcc/ChangeLog-2014
> > 
> > to identify the commit that archived the ChangeLog:
> > 
> > commit e64e0023b9a6796858262f8fd38005a08d234d82
> > Author: green 
> > Date:   Thu Jan 1 15:43:47 2015 +
> > 
> >  Roll ChangeLog file.  Limit offsets to 16 bits for moxie.
> > 
> > 
> > Once you have that commit you can use "^" to find the prior state of
> > the tree, and then use git blame:
> > 
> >git blame e64e0023b9a6796858262f8fd38005a08d234d82^ gcc/ChangeLog
> 
> Thanks for your hint!
> 
> > 
> > and then search for the text of interest:
> > 
> > 9296020474 (tbsaunde  2014-05-17 23:15:55 + 38073) 2014-05-17  
> > Trevor Saunders  
> > 9296020474 (tbsaunde  2014-05-17 23:15:55 + 38074)
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38075)  * 
> > ggc-common.c (ggc_internal_cleared_alloc): Adjust.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38076)  * 
> > ggc-none.c (ggc_internal_alloc): Assert if a finalizer is passed.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38077)  
> > (ggc_internal_cleared_alloc): Likewise.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38078)  * 
> > ggc-page.c (finalizer): New class.
> > b540cb16c9 (uros  2014-05-18 07:24:24 + 38079)  
> > (vec_finalizer): Likewise.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38080)  
> > (globals::finalizers): New member.
> > b540cb16c9 (uros  2014-05-18 07:24:24 + 38081)  
> > (globals::vec_finalizers): Likewise.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38082)  
> > (ggc_internal_alloc): Record the finalizer if any for the block bei
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38083)  allocated.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38084)  
> > (ggc_handle_finalizers): New function.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38085)  
> > (ggc_collect): Call ggc_handle_finalizers.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38086)  * ggc.h 
> > (ggc_internal_alloc): Add arguments to allow installing a
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38087)  finalizer.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38088)  
> > (ggc_internal_cleared_alloc): Likewise.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38089)  (finalize): 
> > New function.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38090)  
> > (need_finalization_p): Likewise.
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38091)  
> > (ggc_alloc): Install the type's destructor as the finalizer if it
> > 92f06184bb (tbsaunde  2014-05-17 23:08:00 + 38092)  m

Re: C++ xgcc for arm-none-eabi fails in 7.1, 7.2 due to undefined identifiers

[Kai Ruottu]

R0b0t1 kirjoitti 18.8.2017 klo 19:17:

On Fri, Aug 18, 2017 at 1:09 AM, Freddie Chopin  wrote:

On Thu, 2017-08-17 at 22:27 -0500, R0b0t1 wrote:

On Thu, Aug 17, 2017 at 4:44 PM, R0b0t1  wrote:

When compiling libssp, ssp.c, function __guard_setup:
O_RDONLY is undeclared (ssp.c:93:34),
ssize_t is an unknown type name (ssp.c:96:7), and
size_t is an unknown type name (ssp.c:113:25).

../../src/gcc-7.2.0/configure --target=$TARGET --prefix=$PREFIX
--with-cpu=cortex-m4 --with-fpu=fpv4-sp-d16 --with-float=hard
--with-mode=thumb --enable-multilib --enable-interwork
--enable-languages=c,c++ --with-system-zlib --with-newlib
--disable-shared --disable-nls --with-gnu-as --with-gnu-ld

A bootstrap C compiler is generated properly when passing --
without-headers.


All this talk about a "bootstrap C compiler", "magic scripts" etc. puts 
me to think there being
serious ignorance about how to simply produce a newlib-based 
crosstoolchain using the
traditional method : Putting gmp, mpc and mpfr sources for the host 
libraries and newlib &
libgloss subdirs from the newlib sources, among the GCC sources and the 
building everything

in only one stage...

I tried the traditional method and there were no problems. No weird 
"bootstrap stage", no weird
scripts required, only building binutils and then GCC with newlib after 
symlinking the extra srcs

into the main GCC source directory...

Here is the last rows from the build and then 'ls' for the $target stuff 
and trying the new GCC

driver :

make[5]: Siirrytään hakemistoon 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/thumb/libquadmath"

make  all-am
make[6]: Siirrytään hakemistoon 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/thumb/libquadmath"

true  DO=all multi-do # make
make[6]: Poistutaan hakemistosta 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/thumb/libquadmath"
make[5]: Poistutaan hakemistosta 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/thumb/libquadmath"
make[5]: Siirrytään hakemistoon 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/fpu/libquadmath"

make  all-am
make[6]: Siirrytään hakemistoon 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/fpu/libquadmath"

true  DO=all multi-do # make
make[6]: Poistutaan hakemistosta 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/fpu/libquadmath"
make[5]: Poistutaan hakemistosta 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/fpu/libquadmath"
make[4]: Poistutaan hakemistosta 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/libquadmath"
make[3]: Poistutaan hakemistosta 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/libquadmath"
make[2]: Poistutaan hakemistosta 
"/home/src-old/gcc-7.2.0/build/arm-cortex-eabi/libquadmath"

make[1]: Poistutaan hakemistosta "/home/src-old/gcc-7.2.0/build"
[root@localhost build]# ls arm-cortex-eabi
fpu  libgcc  libgloss  libquadmath  libssp  libstdc++-v3  newlib thumb
[root@localhost build]# gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=gcc/xgcc
Target: arm-cortex-eabi
Configured with: ../configure --build=i686-linux-gnu 
--host=i686-linux-gnu --target=arm-cortex-eabi --prefix=/opt/cross 
--libdir=/opt/cross/lib --libexecdir=/opt/cross/lib --with-cpu=cortex-m4 
--with-fpu=fpv4-sp-d16 --with-float=hard --with-mode=thumb 
--enable-multilib --enable-interwork --enable-languages=c,c++ 
--with-newlib --disable-shared --disable-nls 
--with-gxx-include-dir=/opt/cross/include/c++/7.2.0 
--enable-version-specific-runtime-libs --program-prefix=arm-cortex-eabi- 
--program-suffix=-7.2

Thread model: single
gcc version 7.2.0 (GCC)

Re: Overwhelmed by GCC frustration

[Segher Boessenkool]

On Thu, Aug 17, 2017 at 05:22:34PM +, paul.kon...@dell.com wrote:
> I think G-J said "...  LRA focusses just comfortable, orthogonal targets" 
> which is not quite the same thing.
> 
> I'm a bit curious about that, since x86 is hardly "comfortable orthogonal".  
> But if LRA is targeted only at some of the ISA styles that are out in the 
> world, which ones are they, and why the limitation?

LRA does better with more regular register sets, but then again, everything
has a much easier time with regular register sets.

> One of GCC's great strength is its support for many ISAs.

100% agreed.

> Not all to the same level of excellence, but there are many, and adding more 
> is easy at least for an initial basic level of support.  When this is needed, 
> GCC is the place to go.
> 
> I'd like to work on moving one of the remaining CC0 targets to the new way, 
> but if the reality is that GCC is trying to be "mainstream only" then that 
> may not be a good way for me to spend my time.

That is not at all GCC's goal.  See the mission statement:

https://gcc.gnu.org/gccmission.html

More often used platforms naturally get better support, have more people
working on them.  And for releases those platforms are more important
than others, which is just a practical thing (bugs on those affect more
people, it can be hard to find people to solve a problem on a minority
platform quickly enough).  https://gcc.gnu.org/gcc-8/criteria.html

But all targets matter, variety is good, also in GCC's self-interest.


Segher