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

2017-08-17 Thread Freddie Chopin
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

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

2017-08-17 Thread Freddie Chopin
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:

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

2017-08-17 Thread R0b0t1
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 --p

Re: Optimization breaks inline asm code w/ptrs

2017-08-17 Thread Alan Modra
On Thu, Aug 17, 2017 at 04:27:12PM +0200, Michael Matz wrote: > Hi, > > On Mon, 14 Aug 2017, Alan Modra wrote: > > > I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to track > > the lack of documentation. > > You mean like in this paragraph discussing memory clobbers and uses in

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

2017-08-17 Thread Leslie Zhai
在 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-ge

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

2017-08-17 Thread Michael Clark
> On 18 Aug 2017, at 11:13 AM, Michael Clark wrote: > > So it is a bug on arm too? and can be done with one sbfiz instruction? > (assuming I’m understand sbfiz from my first reading) e.g. > > sbfiz w0, w0, 0, 2 >ret Getting my 3’s and 5’s swapped. Confused by gcc. sbfiz w0,

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

2017-08-17 Thread Michael Clark
> On 18 Aug 2017, at 10:41 AM, Andrew Pinski wrote: > > On Thu, Aug 17, 2017 at 3:29 PM, 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 anoth

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

2017-08-17 Thread Andrew Pinski
On Thu, Aug 17, 2017 at 3:29 PM, 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 > tric

gcc-7-20170817 is now available

2017-08-17 Thread gccadmin
Snapshot gcc-7-20170817 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170817/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7

Bit-field struct member sign extension pattern results in redundant

2017-08-17 Thread Michael Clark
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

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

2017-08-17 Thread R0b0t1
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 -

Re: Overwhelmed by GCC frustration

2017-08-17 Thread R0b0t1
On Thu, Aug 17, 2017 at 12:36 PM, Bin.Cheng wrote: > Your work will contribute to this and must be highly appreciated :) > I apologize for interjecting as I do not understand GCC internals very well, but I appreciate all of the work that is contributed to GCC, especially by individuals on their o

Re: Overwhelmed by GCC frustration

2017-08-17 Thread Paul.Koning
> On Aug 17, 2017, at 1:36 PM, Bin.Cheng wrote: > > On Thu, Aug 17, 2017 at 6:22 PM, wrote: >> >> ... >> One of GCC's great strength is its support for many ISAs. Not all to the >> same level of excellence, but there are many, and adding more is easy at >> least for an initial basic level

Re: Overwhelmed by GCC frustration

2017-08-17 Thread Bin.Cheng
On Thu, Aug 17, 2017 at 6:22 PM, wrote: > >> On Aug 17, 2017, at 11:22 AM, Oleg Endo wrote: >> >> On Wed, 2017-08-16 at 19:04 -0500, Segher Boessenkool wrote: >>> >>> LRA is easier to work with than old reload, and that makes it better >>> maintainable. >>> >>> Making LRA handle everything reloa

Re: Overwhelmed by GCC frustration

2017-08-17 Thread Paul.Koning
> On Aug 17, 2017, at 11:22 AM, Oleg Endo wrote: > > On Wed, 2017-08-16 at 19:04 -0500, Segher Boessenkool wrote: >> >> LRA is easier to work with than old reload, and that makes it better >> maintainable. >> >> Making LRA handle everything reload did is work, and someone needs to >> do it. >

Re: Overwhelmed by GCC frustration

2017-08-17 Thread Oleg Endo
On Wed, 2017-08-16 at 19:04 -0500, Segher Boessenkool wrote: >  > LRA is easier to work with than old reload, and that makes it better > maintainable. > > Making LRA handle everything reload did is work, and someone needs to > do it. > > LRA probably needs a few more target hooks (a _few_) to gui

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

2017-08-17 Thread 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 Alloc

Re: Optimization breaks inline asm code w/ptrs

2017-08-17 Thread Michael Matz
Hi, On Mon, 14 Aug 2017, Alan Modra wrote: > I've opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81845 to track > the lack of documentation. You mean like in this paragraph discussing memory clobbers and uses in extended asms that we have since 2004? : If your assembler

Re: Release Signing Keys are Susceptible to Attack

2017-08-17 Thread Paul.Koning
> On Aug 17, 2017, at 4:39 AM, Richard Biener > wrote: > > On Thu, Aug 17, 2017 at 4:23 AM, R0b0t1 wrote: >> After downloading and verifying the releases on >> ftp://ftp.gnu.org/gnu/, I found that the maintainers used 1024 bit DSA >> keys with SHA1 content digests. 1024 bit keys are considered

Re: GCC 7.2 Released

2017-08-17 Thread Jonathan Wakely
On 17 August 2017 at 06:02, Klaus Kruse Pedersen (Klaus) wrote: >> The GNU Compiler Collection version 7.2 has been released. > > Shouldn't the release have a tag on git? > > It doesn't seem to be there: https://gcc.gnu.org/git/?p=gcc.git;a=tags > > > git tag gcc-7_2_0-release 1bd23ca8c30f4827c4be

Re: Release Signing Keys are Susceptible to Attack

2017-08-17 Thread Richard Biener
On Thu, Aug 17, 2017 at 4:23 AM, R0b0t1 wrote: > After downloading and verifying the releases on > ftp://ftp.gnu.org/gnu/, I found that the maintainers used 1024 bit DSA > keys with SHA1 content digests. 1024 bit keys are considered to be > susceptible to realistic attacks, and SHA1 has been consi