Make your AutoCad Experience More Awesome with HP Z Workstation!

[Logicom]

Logicom | Autodesk
Make your AutoCad Experience More Awesome with HP Z Workstation!
https://gfcmedia.com/wp-content/uploads/2018/10/18.10.12-adsk_hp.pdf
email: market...@logicom-me.net (mailto:market...@logicom-me.net)  Tel: (+961) 
1 698 220 (tel:+9611698220)
Dekwaneh, Industrial Zone, Maurice Jabra Bldg, GF
To Stop Receiving our email please reply with REMOVE
this email was sent by GFC.media (https://gfc.media/)

https://gfc.media/
Know more about how you can reach more clients
visit www.GFCmedia.com (http://www.gfcmedia.com/email)  or call
Beirut (+961) 70 6 58 666  Dubai (+971) 5  5 338

Disclaimer: GFC is not responsible for any contents linked to this email, as 
they are only related to the advertiser and do not represent GFC in any way.

This email was sent to gcc@gcc.gnu.org (mailto:gcc@gcc.gnu.org)
why did I get this? 
(https://battleparkae.us19.list-manage.com/about?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=4aafd6bcaf&c=7c55a2168d)
 unsubscribe from this list 
(https://battleparkae.us19.list-manage.com/unsubscribe?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=4aafd6bcaf&c=7c55a2168d)
 update subscription preferences 
(https://battleparkae.us19.list-manage.com/profile?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=4aafd6bcaf)
BP AE . UAE . Dubai  . United Arab Emirates

SAP Business One Demo at your offices

[Procons-4it]

Dear Business Partner,



ProCons4IT team in Lebanon is glad to schedule a demo of SAP Business One 
complete ERP software solution at your offices to showcase how it can help you 
cope with digital transformation.



ProCons 4IT is the largest SAP Business One partner in Middle East and TOP 10 
globally with more than 50 consultants across all its offices. SAP Business One 
is the ideal integrated ERP software solution on Premise or Cloud for Small to 
Medium companies around the world with more than 50 clients in Lebanon and 
60,000 worldwide. It manages all your business from Finance, Accounting, Sales, 
Stock, Inventory to Warehouse, production, HR & Payroll all in one screen.



Please reply to this message with your preferred date/time and will be happy to 
contact you asap to confirm accordingly.



We look forward to meeting with you very soon.



Warm Regards,



ProCons 4IT Team.

Run better with SAP. Run simple with SAP Business One.



Procons 4 IT
Al Moudir Bldg, 3^rd Floor, Jal El Dib
Beirut, Lebanon

Phone : +961 4 725601 (tel:+96120420725601) /2/3
www.procons-4it.com 
(https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.procons-4it.com%2F&data=02%7C01%7Ctarek.hamdan%40procons-4it.com%7Ccdcba7b8ef6b4cebf7ea08d62e778721%7C5cab5bf6d1834be397b42a5ff8c5d330%7C1%7C0%7C636747488251771984&sdata=QhHZaB%2BjUNdyzzbdvFQYzNgmVSas8qlaw1VbNSXvPyU%3D&reserved=0)

ProCons  sap

SAP Master Value Added Reseller (VAR)
Lebanon, Dubai, KSA, Kuwait, Qatar, Oman

sap

To Stop Receiving our email please reply with REMOVE
You received this email because you are in GFC.media (https://gfc.media/)  
newsletter list

This email was sent to gcc@gcc.gnu.org (mailto:gcc@gcc.gnu.org)
why did I get this? 
(https://battleparkae.us19.list-manage.com/about?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=4aafd6bcaf&c=5428d1b656)
 unsubscribe from this list 
(https://battleparkae.us19.list-manage.com/unsubscribe?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=4aafd6bcaf&c=5428d1b656)
 update subscription preferences 
(https://battleparkae.us19.list-manage.com/profile?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=4aafd6bcaf)
BP AE . UAE . Dubai  . United Arab Emirates

Re: Kernel build cc1: error: code model kernel does not support 32 bit mode

[Damian Tometzki]

Hello,
problem is solved wrong build, target was defined. 

Best regards
Damian

Re: Trying to debug a testsuite failure

[Jeff Law]

On 10/23/18 11:05 AM, Paul Koning wrote:
> 
> 
>> On Oct 23, 2018, at 6:08 AM, Richard Biener  
>> wrote:
>>
>> On Tue, Oct 23, 2018 at 2:39 AM Paul Koning  wrote:
>>>
>>> In running the gcc testsuite on pdp11, I get some failures like this:
>>>
>>> collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm 
>>> returned 1 exit status
>>> compilation terminated.
>>> compiler exited with status 1
>>> FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation,  -O3 
>>> -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
>>>
>>> While those tests flags are not terribly useful on a small memory platform 
>>> like pdp11, I wouldn't expect a failure like that.  Some tests with those 
>>> flags do pass.
>>>
>>> The real issue is that collect2 is apparently failing for no visible reason 
>>> and without any helpful explanation of what it's trying to do.  Any hints 
>>> on how I might debug this?
>>
>> Try with -Wl,-debug -Wl,-v but then it already tells you that nm
>> failed somehow.  So possibly debug
>> that via strace -f?
>>
>> Richard.
> 
> Found the problem.  By default (without a suitable linker script) the linker 
> does not report memory overflow.  The failing cases are all programs too 
> large to fit in the 16 bit address space of the target.  
> 
> I changed the board file to specify a linker script with explicit memory 
> bounds, and a torture options override that omits the -O3 variants.  Now I 
> get sane results.
> 
Yea.  You also have to watch out for things which fit in the memory map
statically but where your stack/heap will collide at runtime.  I saw
this all the time when I used to do embedded work on 16 bit targets.

jeff

Re: Trying to debug a testsuite failure

[Paul Koning]

> On Oct 23, 2018, at 6:08 AM, Richard Biener  
> wrote:
> 
> On Tue, Oct 23, 2018 at 2:39 AM Paul Koning  wrote:
>> 
>> In running the gcc testsuite on pdp11, I get some failures like this:
>> 
>> collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 
>> 1 exit status
>> compilation terminated.
>> compiler exited with status 1
>> FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation,  -O3 
>> -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
>> 
>> While those tests flags are not terribly useful on a small memory platform 
>> like pdp11, I wouldn't expect a failure like that.  Some tests with those 
>> flags do pass.
>> 
>> The real issue is that collect2 is apparently failing for no visible reason 
>> and without any helpful explanation of what it's trying to do.  Any hints on 
>> how I might debug this?
> 
> Try with -Wl,-debug -Wl,-v but then it already tells you that nm
> failed somehow.  So possibly debug
> that via strace -f?
> 
> Richard.

Found the problem.  By default (without a suitable linker script) the linker 
does not report memory overflow.  The failing cases are all programs too large 
to fit in the 16 bit address space of the target.  

I changed the board file to specify a linker script with explicit memory 
bounds, and a torture options override that omits the -O3 variants.  Now I get 
sane results.

Thanks,

paul

Re: About GSOC.

[Joseph Myers]

On Tue, 23 Oct 2018, Martin Jambor wrote:

> Hi Joseph,
> 
> this seems related to your proposal GSoC proposal in the beginning
> of this year.  Do you have any comments about Tejas's idea?  Do you

My proposal was designed so that it would be possible to do some small 
piece, that is useful by itself, and so learn about some parts of the 
compiler, and then go onto another piece, and so learn about other parts 
of the compiler - as there are lots of separate pieces that are related, 
but each useful by itself as a contribution to GCC.  The parts Tejas 
refers to are good pieces to be looking at for one such piece (roundeven 
folding for constant arguments) (along with e.g. builtins.def to define 
the built-in functions).

> think this would be a good (part of) a GSoC project next year?

If a suitable mentor is available for it next year.

> > It does tell that roundeven rounds its argument to nearest integral
> > ties to even (least significant bit 0) returning integral value
> > provided that the resulting value is exact.
> > So, for the start, I'd be implementing this functionality for roundeven.
> > As ita said in earlier mails that, similar functions like
> > real_ceil are implemented
> > in real.c and are used in fold-const-call.c.
> > Roundeven might be implemented in similar way. Is it built-in
> > (internal) function means not to be exposed to end-user?
> > Studying some functions like real_ceil, there are call checks
> > (flag_errno_math) so I believe similar would be needed for roundeven.

The expectation for this part of the project would be that calls to both 
__builtin_roundeven and roundeven (and similar functions with f, l, f128 
etc. suffixes) would be folded when the arguments are constants (both 
direct calls with constants such as roundeven (2.5), and cases where 
GIMPLE optimization passes propagate a constant into the call, such as 
"double d = 2.5; return roundeven (d);").  This of course involves various 
internal functions in the compiler to implement that.

If you compile code such as

double
f (void)
{
  double d = 2.5;
  return ceil (d);
}

with -O2 -S -fdump-tree-all, you can look at the generated dump files to 
see which optimization pass the folding into constant 3.0 occurs in.  
Looking at such dumps is an important way of finding your way around the 
optimization passes in the compiler.

> > In real.c where real_ceil is implemented, there are function calls
> > (and implementations) like do_fix_trunc which also then call functions
> > like decimal_do_dix_trunc (maybe the main functionality of
> > do_fix_trunc?, other are just checks, like NaN or qNaN). I did not

You can ignore any cases for decimal floating-point values (do gcc_assert 
(!r->decimal)), given that the project does not involve adding any decimal 
floating-point built-in functions.  That means you should instead 
understand REAL_EXP and the significands of floating-point values, and 
what functions such as clear_significand_below and test_significand_bit 
do, because you'll need to write your own logic like that in do_fix_trunc, 
with appropriate cases for whether the bits with values 0.5 and below form 
part of the significand.

> > understand these functions really and what do they do. Also I did not
> > understand the structure of REAL_VALUE_TYPE (r->cl and etc?)

I suggest looking more closely at the definition of cl in real.h.  It's 
true that it doesn't have a comment specifying its semantics directly, but 
the /* ENUM_BITFIELD (real_value_class) */ should give a strong hint, 
along with the values that are stored in that field.  By looking at how 
all the fields in real_value are used, you should be able to deduce their 
semantics, and then send a GCC patch that adds a comment to each field 
with a more detailed description of its semantics, which would be a useful 
contribution by itself to help people reading real.c code in future.

(struct real_format has more detailed comments on some of the fields.  I 
suggest using those as a model for the comments that ought to be written 
for the fields of struct real_value.)

> > Also when does the real.c and fold-const-call.c comes in picture in
> > the flow of GCC (Is it for GIMPLE level instruction selection (gimple
> > stmnt to corresponding rtl instruction))?

The code you're looking at is used in GIMPLE optimizations, and possibly 
folding before GIMPLE.

Converting roundeven calls with non-constant arguments to appropriate 
instructions (for processors that have them, e.g. x86 with SSE 4.1 and 
later) is also useful, and will involve changes to optabs.def, 
internal-fn.def and target .md files.  But I'd advise doing one 
self-contained piece first (such as the folding for constant arguments) 
before moving on to others (such as generating appropriate instructions 
for the case of non-constant arguments).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: SLP reduction: why there is only loop-aware SLP and no straight line?

[Richard Biener]

On Tue, Oct 23, 2018 at 2:49 PM Anton Youdkevitch
 wrote:
>
> Looking at the examples for gcc SLP reduction I see
> that the reduction variable is defined outside the
> loop. It's OK to have this as an example, I thought.
> However, looking at the actual implementation I found
> out that this is the ONLY SLP reduction gcc does.
>
> /* Detect SLP reduction of the form:
>
> #a1 = phi 
> a2 = operation (a1)
> a3 = operation (a2)
> a4 = operation (a3)
> a5 = operation (a4)
>
> #a = phi 
>
> PHI is the reduction phi node (#a1 = phi  above)
> FIRST_STMT is the first reduction stmt in the chain
> (a2 = operation (a1)).
>
> Return TRUE if a reduction chain was detected.  */
>
> Is there any reasoning behind this other than that
> the loop-aware one is generally more profitable?

The only reasoning is lack of a implementation ...
(read: time).

IIRC I tried to support the case of vector constructors
as additional sink but even that turned out to be non-trivial
(read: more than a few hours of work)

Richard.

> --
>Thanks,
>Anton

SLP reduction: why there is only loop-aware SLP and no straight line?

[Anton Youdkevitch]

Looking at the examples for gcc SLP reduction I see
that the reduction variable is defined outside the
loop. It's OK to have this as an example, I thought.
However, looking at the actual implementation I found
out that this is the ONLY SLP reduction gcc does.

/* Detect SLP reduction of the form:

   #a1 = phi 
   a2 = operation (a1)
   a3 = operation (a2)
   a4 = operation (a3)
   a5 = operation (a4)

   #a = phi 

   PHI is the reduction phi node (#a1 = phi  above)
   FIRST_STMT is the first reduction stmt in the chain
   (a2 = operation (a1)).

   Return TRUE if a reduction chain was detected.  */

Is there any reasoning behind this other than that
the loop-aware one is generally more profitable?

--
  Thanks,
  Anton

Re: About GSOC.

[Martin Jambor]

Hi Joseph,

this seems related to your proposal GSoC proposal in the beginning
of this year.  Do you have any comments about Tejas's idea?  Do you
think this would be a good (part of) a GSoC project next year?

Thanks a lot,

Martin


On Sat, Oct 13 2018, Tejas Joshi wrote:
> Hello.
> I reached asking about GCC GSoC project about adding and
> folding functions
> like roundeven. I could not apply for the idea this year but
> interested in the peoject and
> really hoping it would be carry forwarded. Since I've been studying
> source code and about the project, I think working on this from now
> would give me some heads up and hands on with the source code.
>
> I did study .
> It does tell that roundeven rounds its argument to nearest integral
> ties to even (least significant bit 0) returning integral value
> provided that the resulting value is exact.
> So, for the start, I'd be implementing this functionality for roundeven.
> As ita said in earlier mails that, similar functions like
> real_ceil are implemented
> in real.c and are used in fold-const-call.c.
> Roundeven might be implemented in similar way. Is it built-in
> (internal) function means not to be exposed to end-user?
> Studying some functions like real_ceil, there are call checks
> (flag_errno_math) so I believe similar would be needed for roundeven.
>
> In real.c where real_ceil is implemented, there are function calls
> (and implementations) like do_fix_trunc which also then call functions
> like decimal_do_dix_trunc (maybe the main functionality of
> do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
> understand these functions really and what do they do. Also I did not
> understand the structure of REAL_VALUE_TYPE (r->cl and etc?)
>
> Also when does the real.c and fold-const-call.c comes in picture in
> the flow of GCC (Is it for GIMPLE level instruction selection (gimple
> stmnt to corresponding rtl instruction))?
> Thanks.
>
> Regards,
> -Tejas

Re: Trying to debug a testsuite failure

[Richard Biener]

On Tue, Oct 23, 2018 at 2:39 AM Paul Koning  wrote:
>
> In running the gcc testsuite on pdp11, I get some failures like this:
>
> collect2: fatal error: /Users/pkoning/Documents/svn/buildpdp/gcc/nm returned 
> 1 exit status
> compilation terminated.
> compiler exited with status 1
> FAIL: gcc.c-torture/execute/builtins/memcpy-chk.c compilation,  -O3 
> -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
>
> While those tests flags are not terribly useful on a small memory platform 
> like pdp11, I wouldn't expect a failure like that.  Some tests with those 
> flags do pass.
>
> The real issue is that collect2 is apparently failing for no visible reason 
> and without any helpful explanation of what it's trying to do.  Any hints on 
> how I might debug this?

Try with -Wl,-debug -Wl,-v but then it already tells you that nm
failed somehow.  So possibly debug
that via strace -f?

Richard.

> paul
>

Re: "match.pd" (was: Can support TRUNC_DIV_EXPR, TRUNC_MOD_EXPR in GCC vectorization/scalar evolution -- and/or linearization?)

[Richard Biener]

On Mon, Oct 22, 2018 at 6:35 PM Thomas Schwinge  wrote:
>
> Hi!
>
> Thanks for all your comments already!  I continued looked into this for a
> bit (but then got interrupted by a higher-priority task).  Regarding this
> one specifically:
>
> On Fri, 12 Oct 2018 21:14:11 +0200, Marc Glisse  wrote:
> > On Fri, 12 Oct 2018, Thomas Schwinge wrote:
> >
> > > Hmm, and without any OpenACC/OpenMP etc., actually the same problem is
> > > also present when running the following code through the vectorizer:
> > >
> > >for (int tmp = 0; tmp < N_J * N_I; ++tmp)
> > >  {
> > >int j = tmp / N_I;
> > >int i = tmp % N_I;
> > >a[j][i] = 0;
> > >  }
> > >
> > > ... whereas the following variant (obviously) does vectorize:
> > >
> > >int a[NJ * NI];
> > >
> > >for (int tmp = 0; tmp < N_J * N_I; ++tmp)
> > >  a[tmp] = 0;
> >
> > I had a quick look at the difference, and a[j][i] remains in this form
> > throughout optimization. If I write instead *((*(a+j))+i) = 0; I get
> >
> >j_10 = tmp_17 / 1025;
> >i_11 = tmp_17 % 1025;
> >_1 = (long unsigned int) j_10;
> >_2 = _1 * 1025;
> >_3 = (sizetype) i_11;
> >_4 = _2 + _3;
> >
> > or for a power of 2
> >
> >j_10 = tmp_17 >> 10;
> >i_11 = tmp_17 & 1023;
> >_1 = (long unsigned int) j_10;
> >_2 = _1 * 1024;
> >_3 = (sizetype) i_11;
> >_4 = _2 + _3;
> >
> > and in both cases we fail to notice that _4 = (sizetype) tmp_17; (at least
> > I think that's true).
> >
> > So there are missing match.pd transformations in addition to whatever
> > scev/ivdep/other work is needed.
>
> With a very simplistic "match.pd" rule (not yet any special cases
> checking etc.):
>
> diff --git gcc/match.pd gcc/match.pd
> index b36d7ccb5dc3..4c23116308da 100644
> --- gcc/match.pd
> +++ gcc/match.pd
> @@ -5126,3 +5126,28 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
> { wide_int_to_tree (sizetype, off); })
>   { swap_p ? @0 : @2; }))
> { rhs_tree; })
> +
> +/* Given:
> +
> +   j = in / N_I
> +   i = in % N_I
> +
> +   ..., fold:
> +
> +   out = j * N_I + i
> +
> +   ..., into:
> +
> +   out = in
> +*/
> +
> +/* As long as only considering N_I being INTEGER_CST (which are always second
> +   argument?), probably don't need ":c" variants?  */
> +
> +(simplify
> + (plus:c
> +  (mult:c
> +   (trunc_div @0 INTEGER_CST@1)
> +   INTEGER_CST@1)
> +  (trunc_mod @0 INTEGER_CST@1))
> + (convert @0))
>
> ..., the original code:
>
> int f1(int in)
> {
>   int j = in / N_I;
>   int i = in % N_I;
>
>   int out = j * N_I + i;
>
>   return out;
> }
>
> ... gets simplified from ("div-mod-0.c.027t.objsz1"):
>
> f1 (int in)
> {
>   int out;
>   int i;
>   int j;
>   int _1;
>   int _6;
>
>:
>   gimple_assign 
>   gimple_assign 
>   gimple_assign 
>   gimple_assign 
>   gimple_assign 
>   gimple_return <_6>
>
> }
>
> ... to ("div-mod-0.c.028t.ccp1"):
>
> f1 (int in)
> {
>   int out;
>   int i;
>   int j;
>   int _1;
>
>:
>   gimple_assign 
>   gimple_assign 
>   gimple_assign 
>   gimple_return 
>
> }
>
> (The three dead "gimple_assign"s get eliminated later on.)
>
> So, that works.
>
> However, it doesn't work yet for the original construct that I'd ran
> into, which looks like this:
>
> [...]
> int i;
> int j;
> [...]
> signed int .offset.5_2;
> [...]
> unsigned int .offset.7_23;
> unsigned int .iter.0_24;
> unsigned int _25;
> unsigned int _26;
> [...]
> unsigned int .iter.0_32;
> [...]
>
>  :
> # gimple_phi <.offset.5_2, .offset.5_21(8), .offset.5_30(9)>
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> [...]
>
> Resolving the "a[j][i] = 123" we'll need to look into later.
>
> As Marc noted above, with that changed into "*(*(a + j) + i) = 123", we
> get:
>
> [...]
> int i;
> int j;
> long unsigned int _1;
> long unsigned int _2;
> sizetype _3;
> sizetype _4;
> sizetype _5;
> int * _6;
> [...]
> signed int .offset.5_8;
> [...]
> unsigned int .offset.7_29;
> unsigned int .iter.0_30;
> unsigned int _31;
> unsigned int _32;
> [...]
>
>  :
> # gimple_phi <.offset.5_8, .offset.5_27(8), .offset.5_36(9)>
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> gimple_assign 
> [...]
>
> Here, unless I'm confused, "_4" is supposed to be equal to ".iter.0_30",
> but "match.pd" doesn't agree yet.  Note the many "nop_expr"s here, which
> I have not yet figured out how to handle, I suppose?  I tried som