gcc-9-20190601 is now available

2019-06-01 Thread gccadmin
Snapshot gcc-9-20190601 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/9-20190601/
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/branches/gcc-9-branch 
revision 271839

You'll find:

 gcc-9-20190601.tar.xzComplete GCC

  SHA256=041a3cd82e0a0de3b585fa882ea2d8359ff47c7a218bc79493f8ba7a1d69e53d
  SHA1=21f7af51fc0ba7bea04874671c44c15f83276ac4

Diffs from 9-20190525 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.


ARM peephole2 from 2003 never merged, still valid

2019-06-01 Thread Fredrik Hederstierna
I found this patch from 2003 by Tamas Gergely that was never merged.


Though it seems to still be valid, since when applying it, the CSiBE benchmark 
reduce total code size -170 bytes, making 35 out of 893 files smaller (from -4 
to -12 bytes (1-3 instructions).


Bug


asd


asd


asd



updated patch:


diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 20bdc2bec37..4c924499ad9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2019-06-01  Fredrik Hederstierna  
+Tamas Gergely 
+
+   * gcc/config/arm/arm.md: new peephole2 pattern added for extending
+   move and compare parallelization. Retake from 2003 patch adapted.
+
 2019-06-01  Martin Sebor  

PR middle-end/90694
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index ae582172ab9..753d18fbfc5 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -10951,6 +10951,19 @@
   ""
 )

+; The same as the previous, but with exchanged operands
+;
+(define_peephole2
+  [(set (match_operand:SI 0 "arm_general_register_operand" "")
+   (match_operand:SI 1 "arm_general_register_operand" ""))
+   (set (reg:CC CC_REGNUM)
+   (compare:CC (match_dup 0) (const_int 0)))]
+  "TARGET_ARM"
+  [(parallel [(set (reg:CC CC_REGNUM) (compare:CC (match_dup 1) (const_int 0)))
+ (set (match_dup 0) (match_dup 1))])]
+  ""
+)
+
 (define_split
   [(set (match_operand:SI 0 "s_register_operand" "")
(and:SI (ge:SI (match_operand:SI 1 "s_register_operand" "")



Re: ARM peephole2 from 2003 never merged, still valid

2019-06-01 Thread Fredrik Hederstierna
(Sorry, my mail program crashed...  trying repost, correct now...)


I found this patch from 2003 by Tamas Gergely that was never merged for ARM.


Though it seems to still be valid, since when applying it, the CSiBE benchmark 
reduce total code size -170 bytes, making 35 out of 893 files smaller (from -4 
to -12 bytes (1-3 instructions).


Could it be considered to apply it, since it abviously still is valid and 
reduce code size for ARM 32bit. The peephole2 pattern still is not matched.


Bug

Bug 9663 - [arm] 
gcc-20030127 misses an optimization opportunity

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


Message
https://gcc.gnu.org/ml/gcc-patches/2003-02/msg00204.html


Adapted and updated patch from Tamas Gergely:


diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 20bdc2bec37..4c924499ad9 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2019-06-01  Fredrik Hederstierna  
+Tamas Gergely 
+
+   * gcc/config/arm/arm.md: new peephole2 pattern added for extending
+   move and compare parallelization. Retake from 2003 patch adapted.
+
 2019-06-01  Martin Sebor  

PR middle-end/90694
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index ae582172ab9..753d18fbfc5 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -10951,6 +10951,19 @@
   ""
 )

+; The same as the previous, but with exchanged operands
+;
+(define_peephole2
+  [(set (match_operand:SI 0 "arm_general_register_operand" "")
+   (match_operand:SI 1 "arm_general_register_operand" ""))
+   (set (reg:CC CC_REGNUM)
+   (compare:CC (match_dup 0) (const_int 0)))]
+  "TARGET_ARM"
+  [(parallel [(set (reg:CC CC_REGNUM) (compare:CC (match_dup 1) (const_int 0)))
+ (set (match_dup 0) (match_dup 1))])]
+  ""
+)
+
 (define_split
   [(set (match_operand:SI 0 "s_register_operand" "")
(and:SI (ge:SI (match_operand:SI 1 "s_register_operand" "")



Re: How to insert reference to external symbol in RTL properly?

2019-06-01 Thread Arslan Khan
Thanks for the pointer. That worked for me. I create the reference in
GIMPLE and then patch the assignments with LR register in the RTL
pass. Anyhow still i would like to know what should be the proper way
to do this entirely in RTL pass, is doing so not recommended? maybe
some piece of code that is already doing that?

Thanks,
Arslan

On Fri, May 31, 2019 at 4:37 AM Richard Biener
 wrote:
>
> On Wed, May 29, 2019 at 11:50 PM Arslan Khan  wrote:
> >
> > Are you suggesting that i insert an extern at source level? Wouldn't
> > that decrease the usability of the safe stack drastically? Currently
> > all user has to do is provide an address where we intend to place
> > shadow stack, but if he has to place extern symbols in all using files
> > that would be cumbersome.
> > Besides that even i do that, is there a symbol table maintained by GCC
> > that i can use to access this in an RTL pass?
>
> I'm not suggesting to declare it at source level but you have to create
> and assemble it, see how tree-profile.c uses build_decl.
>
> Richard.
>
> > Thanks,
> > Arslan
> >
> > On Wed, May 29, 2019 at 3:17 AM Richard Biener
> >  wrote:
> > >
> > > On Tue, May 28, 2019 at 1:01 AM Arslan Khan  
> > > wrote:
> > > >
> > > > Hi,
> > > > I am a beginner to GCC and am trying to implement safe stack using a
> > > > GCC Plugin for embedded systems. I am using a cross compiler, with GCC
> > > > version:
> > > >
> > > > arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors
> > > > 6-2018-q4-major) 6.3.1 20170620 (release) [ARM/embedded-6-branch
> > > > revision 249437]
> > > >
> > > > The shadow stack is placed on a different RAM chip and is protected
> > > > using software fault isolation (SFI). For SFI i have used a GIMPLE
> > > > pass, but to save the Link Register in the protected memory i had to
> > > > use an RTL pass, because FWIU GIMPLE has no notion of registers. Anyhow 
> > > > i
> > > > am able to generate insn(s) for saving stack pointer to a symbol
> > > > "shadowStack", created by RTL pass (currently
> > > > there is no indexing, wanted to start simple). Here's the insn
> > > > generated for the prologue:
> > > >
> > > > (insn 21 2 20 2 (set (reg/f:SI 110)
> > > > (symbol_ref:SI ("shadowStack") [flags 0x2])) ./test.c:35 -1
> > > >  (nil))
> > > > (insn 20 21 5 2 (set (mem/c:SI (reg/f:SI 110) [0  S4 A32])
> > > > (reg:SI 14 lr)) ./test.c:35 -1
> > > >  (nil))
> > > >
> > > > I have tried to copy what cc1 actually generated for an external
> > > > reference. The one thing that is different is that there is no
> > > > information about the variable declaration ins symbol_ref as
> > > > shadowStack is not defined in source and is purely introduced by the
> > > > RTL pass.  My plan is to provide shadowStack using a library (which in
> > > > the end version would be an array). I did something similar for GIMPLE
> > > > pass to call functions in an external library and it worked for me.
> > > > However when i run it i get the following error message:
> > > >
> > > > ./test.c: In function 'iowrite_example':
> > > > ./test.c:40:1: error: insn does not satisfy its constraints:
> > > >  }
> > > >  ^
> > > > (insn 21 2 20 (set (reg/f:SI 110)
> > > > (symbol_ref:SI ("shadowStack") [flags 0x2])) ./test.c:35 172
> > > > {*arm_movsi_insn}
> > > >  (nil))
> > > > *** WARNING *** there are active plugins, do not report this as a bug
> > > > unless you can reproduce it without enabling any plugins.
> > > > Event| Plugins
> > > > PLUGIN_ATTRIBUTES   | plugin
> > > > PLUGIN_START_UNIT   | plugin
> > > > PLUGIN_ALL_IPA_PASSES_START  | plugin
> > > > ./test.c:40:1: internal compiler error: in extract_constrain_insn, at
> > > > recog.c:2190
> > > > 0xc8ff4c _fatal_insn(char const*, rtx_def const*, char const*, int, 
> > > > char const*)
> > > > 
> > > > /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/rtl-error.c:108
> > > > 0xc8ffac _fatal_insn_not_found(rtx_def const*, char const*, int, char 
> > > > const*)
> > > > 
> > > > /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/rtl-error.c:119
> > > > 0xc3b8e0 extract_constrain_insn(rtx_insn*)
> > > > 
> > > > /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/recog.c:2190
> > > > 0x104dad2 note_invalid_constants
> > > > 
> > > > /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/config/arm/arm.c:17555
> > > > 0x104fab3 arm_reorg
> > > > 
> > > > /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/config/arm/arm.c:18413
> > > > 0xc8a5e6 execute
> > > > 
> > > > /home/build/toolchain/gcc-arm-none-eabi-6-2017-q2-update/src/gcc/gcc/reorg.c:3952
> > > >
> > > > FWIU these instruction generated are accepted by some RTL templates
> > > > but the constraints on operands are not satisfied. I tried to debug
> > > > the constrain_operands function, and is turns out we are trying to