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

[Richard Biener]

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
> match constraints for arm_movsi_insn pattern. So the constraints were:
>
> constraints[0]const char *0x1a76cf3 "=rk,r,r,r,rk,m"
> constraints[1]const char *0x1a76d02 "rk,I,K,j,mi,rk"
>
> My guess was that it should've matched second last alternative but it
> didn't, but i am pretty sure there is nothing wrong with
> constrain_operands, but something is wrong with the way i generated
> the reference. Is there any place i can look for on how to do this
> properly? if required i can share the code here as well for the pass
> (basically i just used gen_rtx_SYMBOL_REF for creating the reference,
> and to be sure there's only one SYMBOL_REF
> (https://gcc.gnu.org/ml/gcc/2003-06/msg02331.html) i save the ref in a
> global variable). Any pointers on what could be wrong in the way i
> generated the reference? Secondly is there any effort going on
> incorporating safe stack with GCC? Lastly please tell me if this
> question belongs here or gcc-help list? i tried gcc-help but it looks
> like most question there are for GCC users not developers.

You should probably add and assemble the global external variable
early in the compilation.

> Thanks,
> Arslan

Re: On-Demand range technology [2/5] - Major Components : How it works

[Richard Biener]

On Tue, May 28, 2019 at 4:17 PM Andrew MacLeod  wrote:
>
> On 5/27/19 9:02 AM, Richard Biener wrote:
> > On Fri, May 24, 2019 at 5:50 PM Andrew MacLeod  wrote:
> >>
> >>> The above suggests that iff this is done at all it is not in GORI because
> >>> those are not conditional stmts or ranges from feeding those.  The
> >>> machinery doing the use-def walking from stmt context also cannot
> >>> come along these so I have the suspicion that Ranger cannot handle
> >>> telling us that for the stmt following above, for example
> >>>
> >>>if (_5 != 0)
> >>>
> >>> that _5 is not zero?
> >>>
> >>> Can you clarify?
> >> So there are 2 aspects to this.the range-ops code for DIV_EXPR, if
> >> asked for the range of op2 () would return ~[0,0] for _5.
> >> But you are also correct in that the walk backwards would not find this.
> >>
> >> This is similar functionality to how null_derefs are currently handled,
> >> and in fact could probably be done simultaneously using the same code
> >> base.   I didn't bring null derefs up, but this is a good time :-)
> >>
> >> There is a separate class used by the gori-cache which tracks the
> >> non-nullness property at the block level.It has a single API:
> >> non_null_deref_p (name, bb)which determines whether the is a
> >> dereference in any BB for NAME, which indicates whether the range has an
> >> implicit ~[0,0] range in that basic block or not.
> > So when we then have
> >
> >   _1 = *_2; // after this _2 is non-NULL
> >   _3 = _1 + 1; // _3 is non-NULL
> >   _4 = *_3;
> > ...
> >
> > when a on-demand user asks whether _3 is non-NULL at the
> > point of _4 = *_3 we don't have this information?  Since the
> > per-BB caching will only say _1 is non-NULL after the BB.
> > I'm also not sure whether _3 ever gets non-NULL during
> > non-NULL processing of the block since walking immediate uses
> > doesn't really help here?
> presumably _3 is globally non-null due to the definition being (pointer
> + x)  ... ie, _3 has a global range o f ~[0,0] ?

No, _3 is ~[0, 0] because it is derived from _1 which is ~[0, 0] and
you cannot arrive at NULL by pointer arithmetic from a non-NULL pointer.

> >
> > So this seems to be a fundamental limitation [to the caching scheme],
> > not sure if it is bad in practice.
> >
> > Or am I missing something?
> >
>
> Not missing anything  The non-nullness property is maintains globally at
> the basic block level.  both _1 and _3 are flagged as being non-null in
> the block.  Upon exit, its a bit check.   If the global information does
> not have the non-nullness property, then when a request is made for
> non-nullness  and the def and the use are both within the same block,
> and its flagged as being non-null in that block, then the request is
> forced back to a quick walk between the def and the use to see if there
> is any non-nulless introduced in between.   Yes, that makes it a linear
> walk, but its infrequent, and often short.  to the best of our knowledge
> at this point anyway :-)

So with the clarification above do we ever see that _3 is non-NULL?
I suppose the worker processing _3 = _1 + 1 would ask for
_1 non-nullness but we do not record any non-NULL-ness of _1 in
this basic-block (but only at its end).  Consider stmts

 _4 = (uintptr_t) _2;
 _5 = _6 / _4;
 _1 = *_2;
...

here at _1 we know _2 is not NULL.  But if we ask for non-NULLness
of _2 at the definition of _4 we may not compute ~[0, 0] and thus
conclude that _6 / _4 does not trap.

stmt-level tracking of ranges are sometimes important.  This is
something the machinery cannot provide - correct?  At least not
optimistically enough with ranges derived about uses.

> >>
> >> yes, compile-time complexity is from empirical speed timings and
> >> theory-crafting from the algorithms,  and that the on-entry cache
> >> prevents multiple passes over things.
> >>
> >> we have not done a memory analysis yet, not done anything to see if we
> >> can improve it.
> >> It makes very heavy use of bitmaps, which are typically quite sparse.
> >> The on-entry cache is a vector of pointers to a range, initially 0, and
> >> we allocate ranges as needed.   There will be an on-entry range entry
> >> for any ssa-name which has been queried between the query point and the
> >> definition.
> > So that's similar to LIVE-on-entry thus a SSA name with a range
> > will have an on-entry range entry on each BB it dominates?
> > That makes storage requirement quadratic in the worst case.
> Yes, assuming a request has been made for all ssa-names everywhere they
> are live.

You did propose to replace [E]VRP with a walk over the whole function
querying ranges and simplifying stmts, did you?

> >>   My belief is this is typically not large, but we have done
> >> no analysis as yet.  This does mean that once an ssa-name goes
> >> "out-of-scope", ie no  more uses in the program, it will not be in the
> >> cache for any of those blocks simply because its never queried past its
> >> end of life.
> >>> Not sure wh

Re: About GSOC.

[Tejas Joshi]

Hello.
My exams are finally over and I have started to address these points now. I
intend to give my most of the time cause of holidays and will try to
consider most of the cases for the patch this time .

Thanks,
-Tejas

On Tue, 21 May 2019 at 03:18, Joseph Myers  wrote:

> On Mon, 20 May 2019, Martin Jambor wrote:
>
> > in addition to the things already pointed out by Joseph, I have the
> > following comments.  But as Joseph has already pointed out, you should
> > also test your patch on __float128 types, so please make sure your code
> > gets invoked and works for something like:
> >
> > if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
> >   link_error (__LINE__);
>
>  ... but with the f128 constant suffix not q, so it works on more
> architectures (all those with _Float128 support, not just those with older
> __float128 support).
>
> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven",
> BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf",
> BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl",
> BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> >
> > ...and for the code to trigger for __builtin_roundevenf128 you have to
> > define this builtin function too.  The easiest way is to do it in the
> > same way it is done for BUILTIN_ROUND and many other functions, i.e. use
> > DEF_EXT_LIB_FLOATN_NX_BUILTINS.
>
> Also note that TS 18661-1 has been merged into C2X.  I haven't yet updated
> glibc headers to reflect this, but this means a new DEF_C2X_BUILTIN should
> be added similar to DEF_C11_BUILTIN, and used for those three new
> functions, instead of DEF_EXT_LIB_BUILTIN.  (And for the strdup and
> strndup built-in functions, also added to C2X, but that's independent of
> the present project.)
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
>

Re: On-Demand range technology [3/5] - The Prototype

[Richard Biener]

On Tue, May 28, 2019 at 4:41 PM Jeff Law  wrote:
>
> On 5/23/19 7:10 AM, Richard Biener wrote:
> > On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod  wrote:
> >>
> >> There is a functioning prototype in branch “ssa-range” which is a proof
> >> of concept that the approach is functional as well as quick, and can be
> >> used to answer questions which come up regarding what it can and can’t
> >> do.  Our last merge was on April 13th, so it's fairly up to date.
> >>
> >> We have implemented a flexible range class (irange) which allows for
> >> multiple subranges to represent a range, and which can be extended in
> >> the future to types other than integral. We use this throughout, but it
> >> could be replaced in the ranger with any similar API. Conversion
> >> routines are also provided to convert from irange to value_range and
> >> value_range to irange.
> >>
> >> A full set of tree_code range-op routines are implemented.  We have
> >> commoned as much code as possible with the existing VRP range extraction
> >> code.  Also, we have added additional code for calculating the other
> >> operands from a known result in numerous cases.
> >>
> >> The code base in VRP has been modified (via a flag) to
> >>  - Work completely with the native value_range like it does today.
> >>  - Use irange and the range-ops component under the covers to
> >> extract ranges. Requests in VRP are then converted from value_ranges to
> >> irange, called into the range-op routines, and then converted back to
> >> value_range for VRP/EVRP’s use.
> >>  - Do operations both ways and compare the results to make sure both
> >> agree on the range, and trap if they do not.
> >>
> >> The branch defaults to the compare and trap mode to ensure everything is
> >> working correctly. This has been our correctness model for statement
> >> range extraction and was active during the Fedora package builds. The
> >> only time we disabled it was to do performance runs vs RVRP, and were
> >> looking at both branch and trunk times for EVRP and VRP.
> >>
> >> Of note, we drop all symbolics in ranges to VARYING on everything except
> >> PLUS and MINUS, which we leave as native calculations if there are
> >> symbolics present.  More on symbolics later.
> >>
> >> A VRP like pass called RVRP has been implemented.
> >>  - The vr-values statement simplification code has been factored out
> >> to be range agnostic, meaning that these routines can operate on either
> >> value_range or irange. Thus, we are using a common code base to perform
> >> statement simplification as well.
> >>  - For complete compatibility with EVRP, the RVRP pass builds
> >> dominators and instantiates the SCEV loop information so we have loop
> >> range info available. RVRP does not need this info to run, but would
> >> miss some of the test cases which depend on loop ranges.
> >>  - RVRP is set up to demonstrate it can process the IL in multiple
> >> directions and bootstraps/passes all tests in all directions.
> >>  * Dominator order
> >>  * Post-dominator order
> >>  * BB1 thru BBn
> >>  * BBn thru BB1
> >>  * branch-only mode where only branches at the end of each BB
> >> are examined for folding opportunities
> >>
> >> 4 additional passes have been converted to use the ranger model:
> >>  - sprintf - removed the dominator building/walking
> >>  - warn alloca - replaced calls to get global ranges with calls that
> >> now return context sensitive ranges.
> >>  - warn restrict - just replaced EVRP range calls with ranger calls.
> >>  - backwards threader - enhanced to use contextual range information
> >> to make additional threading decisions.
> >>
> >>
> >> Symbolic Ranges
> >>
> >> One big concern last year expressed was my decision to abolish symbolic
> >> ranges.
> >>
> >> I continue to maintain that there is no need to track the range of x_2
> >> as [y_3 + 5, MAX] for x_2 = y_3 + 5.   All you need to do is look at the
> >> definition of x_2, and the same information is exposed right there in
> >> the IL.  If one requires the symbolic information, the same on-demand
> >> process could lookup that information as well. This in turn, makes the
> >> code for ranges much simpler, easier to maintain, and less likely to
> >> introduce bugs.
> >>
> >> We have found through our prototype that symbolics in ranges are not
> >> nearly as prevalent as one would think.   During the work to share a
> >> common code base with VRP, we found that symbolic ranges are irrelevant
> >> for everything except PLUS_EXPR and MINUS_EXPR. The shared code in our
> >> branch drops symbolics to varying immediately for everything else, and
> >> it has no impact on EVRP, or VRP or any tests we can find anywhere.
> >> Furthermore, we never trapped while comparing ranges generated by VRP
> >> versus generating them with range-ops which drops symbolics to varying.
> >>
> >> We tried modifying VRP such that we don’t even create symbolic
> >> 

Re: [9/10 Regression] [PR87833] Intel MIC (emulated) offloading still broken

[Thomas Schwinge]

Hi Ilya!

On Thu, 9 May 2019 15:46:06 +0300, Ilya Verbin  wrote:
> I have left Intel 3 years ago. If you have any questions regarding MIC
> offloading, you can reach me by iver...@gmail.com

We're (a) looking for somebody to step up as a maintainer for that, and
(b) that person to get active, and take ownership of
, and review the proposed patch,
.


Grüße
 Thomas


signature.asc
Description: PGP signature

Re: [9/10 Regression] [PR87833] Intel MIC (emulated) offloading still broken

[Jeff Law]

On 5/29/19 8:32 AM, Thomas Schwinge wrote:
> Hi Ilya!
> 
> On Thu, 9 May 2019 15:46:06 +0300, Ilya Verbin  wrote:
>> I have left Intel 3 years ago. If you have any questions regarding MIC
>> offloading, you can reach me by iver...@gmail.com
> 
> We're (a) looking for somebody to step up as a maintainer for that, and
> (b) that person to get active, and take ownership of
> , and review the proposed patch,
> .
My question would be where in the world is the -fno-pie stuff coming
from.  It's also not clear where mkoffload is being called within c#5
(presumably via the linker plugin) AFAICT we don't get the command line
for that.  -v  or -Wl,-v probably would have helped.  It's difficult to
know if HJ's patch is correct or not given the missing bits of information.

But I'm willing to trust HJ here.  I'll ack the patch for the trunk.
You or HJ can go ahead and install it.

THe bigger question about the viability/usability of MIC is punted ;-)

jeff

Re: About GSOC.

[Tejas Joshi]

Hello.
I tried to check the values for significand words using _Float128
using a test program with value larger than 64 bit.
Test program :

int main ()
{
_Float128 x = 18446744073709551617.5;   (i.e. 2^64 + 1.5 which is
certainly longer than 64-bit)
_Float128 y = __builtin_roundf128 (x);
}

The lower words of significand (sig[1] and sig[0] for 64-bit system)
are still being zero. I haven't included the roundevenf128 yet but
inspecting this on real_round function.
Am I missing something here?

Thanks.


On Wed, 29 May 2019 at 16:56, Tejas Joshi  wrote:
>
> Hello.
> My exams are finally over and I have started to address these points now. I 
> intend to give my most of the time cause of holidays and will try to consider 
> most of the cases for the patch this time .
>
> Thanks,
> -Tejas
>
> On Tue, 21 May 2019 at 03:18, Joseph Myers  wrote:
>>
>> On Mon, 20 May 2019, Martin Jambor wrote:
>>
>> > in addition to the things already pointed out by Joseph, I have the
>> > following comments.  But as Joseph has already pointed out, you should
>> > also test your patch on __float128 types, so please make sure your code
>> > gets invoked and works for something like:
>> >
>> > if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
>> >   link_error (__LINE__);
>>
>>  ... but with the f128 constant suffix not q, so it works on more
>> architectures (all those with _Float128 support, not just those with older
>> __float128 support).
>>
>> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", 
>> > > BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
>> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", 
>> > > BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
>> > > +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", 
>> > > BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
>> >
>> > ...and for the code to trigger for __builtin_roundevenf128 you have to
>> > define this builtin function too.  The easiest way is to do it in the
>> > same way it is done for BUILTIN_ROUND and many other functions, i.e. use
>> > DEF_EXT_LIB_FLOATN_NX_BUILTINS.
>>
>> Also note that TS 18661-1 has been merged into C2X.  I haven't yet updated
>> glibc headers to reflect this, but this means a new DEF_C2X_BUILTIN should
>> be added similar to DEF_C11_BUILTIN, and used for those three new
>> functions, instead of DEF_EXT_LIB_BUILTIN.  (And for the strdup and
>> strndup built-in functions, also added to C2X, but that's independent of
>> the present project.)
>>
>> --
>> Joseph S. Myers
>> jos...@codesourcery.com

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

[Arslan Khan]

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?
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
> > match constraints for arm_movsi_insn pattern. So the constraints were:
> >
> > constraints[0]const char *0x1a76cf3 "=rk,r,r,r,rk,m"
> > constraints[1]const char *0x1a76d02 "rk,I,K,j,mi,rk"
> >
> > My guess was that it should've matched second last alternative but it
> > didn't, but i am pretty sure there is nothing wrong with
> > constrain_operands, but something is wrong with the way i generated
> > the reference. Is there any place i can look for on how to do this
> > properly? if required i can share the code here as well for the pass
> > (basically i just used gen_rtx_SYMBOL_REF for creating the reference,
> > and to be sure there's only one SYMBOL_REF
> > (https://gcc.gnu.org/ml/gcc/2003-06/msg02331.html) i save the ref in a
> > global variable). Any pointers on what could be wrong in the way i
> > generated the reference? Secondly is there any effort going on
> > incorporating safe stack with GCC? Lastly please tell me if this
> > ques

[GSoC'19, libgomp work stealing] baseline benchmark results

[김규래]

​Hi everyone,
Just wanted to share some quick baseline benchmark results [3].
I ran LU decomposition on a AMD Ryzen Threadripper 1950x 16C/32T system.
LAPACK is currently plain loop parallel BLAS as far I believe.
And the upstream version of PLASMA uses OpenMP tasks [1].
The colored region is the 95% confidence interval.
Task parallelism seems to scale pretty well on such a small scale benchmark.
I hope work-stealing could improve this even more.
An
 
Ray Kim
 
[1] YarKhan, Asim, et al. "Porting the PLASMA numerical library to the OpenMP 
standard." International Journal of Parallel Programming 45.3 (2017): 612-633.
[2] https://bitbucket.org/icl/plasma/src/default/
[3] Link to benchmark plot: https://m.imgur.com/ysxs5ol
 

The bankruptcy

[Ryan]

I believe I was supposed to be informed of the bankruptcy. I need to confirm 
I’m the foreign debtor.  My name is Ryan Bolen. How do I submit documents if I 
am.  I was not informed of this at all. Please pass on my info to the trustee 
or whoever.  I’ll talk with my lawyer tomorrow.  And submit what needs to be 
submitted if so. Please confirm.