gcc@gcc.gnu.org ISF FORM INVOICE
Dear Customer gcc@gcc.gnu.org
SAP Business One Demo at your offices
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=f9bb640b61) unsubscribe from this list (https://battleparkae.us19.list-manage.com/unsubscribe?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=4aafd6bcaf&c=f9bb640b61) update subscription preferences (https://battleparkae.us19.list-manage.com/profile?u=90bac0906b280fc6945d7b273&id=4a9f8b0547&e=4aafd6bcaf) BP AE . UAE . Dubai . United Arab Emirates
C++ compat symbol not emitted anymore in GCC 8
This is seen in a distro upgrade, with a shared library built using GCC 6, which
now fails to dynamically link, when the library is rebuilt using GCC 8.
Details in https://bugs.debian.org/911090
Jonathan pointed me to PR71712, fixing the C++ mangling.
$ cat > foo.C
#include
struct foo {
operator std::string();
};
foo::operator std::string() { return "Hi"; }
$ g++-8 -shared -fPIC -o libfoo.so foo.C && nm -D libfoo.so | grep foo
1136 T
_ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcv
g++-7 -shared -fPIC -o libfoo.so foo.C && nm -D libfoo.so | grep foo
115a T
_ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
115a T
_ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcv
$ g++-8 -fabi-version=10 -shared -fPIC -o libfoo.so foo.C && nm -D libfoo.so |
grep foo
1136 T
_ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEB5cxx11Ev
1136 T
_ZN3foocvNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcv
GCC 7 emits the old/compat symbol, and GCC 8 emits it when explicitly built with
-fabi-version=10. This ABI change results in silent breakage, maybe in more
libraries than that one. Is there a reason that this compat symbol isn't
emitted anymore in GCC 8?
Matthias
how to build and test uClinux toolchains
Hi, While reviewing one of my patches about FDPIC support for ARM, Richard raised the concern of testing the patch on other uClinux targets [1]. I looked at uclinux.org and at the GCC maintainers file, but it's still not obvious to me which uClinux targets are currently supported? I'd like to do a basic: - build toolchain for target XXX, make check - apply my GCC patch - build toolchain for target XXX, make check again - compare the results to make sure I didn't break anything I'd appreciate hints on which targets offer to do that easily enough, using a simulator (qemu?). Thanks, Christophe [1] https://gcc.gnu.org/ml/gcc-patches/2018-10/msg00736.html
[RFC][GCC][mid-end] Support vectorization of complex numbers using machine instructions.
Hi All,
I am trying to add support to the auto-vectorizer for complex operations where
a target has instructions for.
The instructions I have are only available as vector instructions. The
operations
are complex addition with a rotation or complex fmla with a rotation for
half floats, floats and doubles.
They expect the complex number to be broken down and stored in vectors as
real/img parts. GCC already does this first part when it lowers complex numbers
very early on in tree, so that's good.
As a simple example, I am trying to get GCC to emit an internal function
.FCOMPLEX_ADD_ROT_90 (Complex addition with a 90* rotation)
when the target supports it.
my C example is:
void f90 (double complex a[N], double complex b[N], double complex c[N])
{
for (int i=0; i < N; i++)
c[i] = a[i] + b[i] * I;
}
Which in tree looks like
_3 = a_15(D) + _2;
_12 = REALPART_EXPR <*_3>;
_22 = IMAGPART_EXPR <*_3>;
_5 = b_16(D) + _2;
_6 = IMAGPART_EXPR <*_5>;
_8 = REALPART_EXPR <*_5>;
_10 = c_17(D) + _2;
_4 = _12 - _6;
_13 = _8 + _22;
REALPART_EXPR <*_10> = _4;
IMAGPART_EXPR <*_10> = _13;
after some rewriting from match.pd.
what I'm after is for it to get rewritten as something like
_3 = a_15(D) + _2;
_5 = b_16(D) + _2;
_10 = c_17(D) + _2;
*_10 = .FCOMPLEX_ADD_ROT_90 (*_5, *_3)
1) My first attempt to do this was in tree-vect-patterns.c as just another
vectorizer pattern. The first problem is that I need to match a pair of
statements
REALPART_EXPR <*_10> = _4;
IMAGPART_EXPR <*_10> = _13;
and not just a single one. This I can solve with getting the gsi for the
statement being inspected and walking back up the tree to find the second pair.
This works, but I am stopped by that the vectorizer (quite reasonably) doesn't
know what to do when the statement is already a vector stmt. So it bails out
and rejects the pattern substitution.
2) I thought about introducing two internal FN that would be treated as a pair
to
match against later, but not sure this would work. The problem with generating
the two internal functions or doing the whole matching in combine (the
vectorizer
will always vectorize this so I could match the add and sub in a pattern later)
is that I need to prevent it from treating them as a compound structure and
instead just as a normal vector. In AArch64 terms I want to stop it from doing
ld2 (load multiple 2-elem structures) and instead use ld1 loads (load multiple
single element structures). In certain cases (rotations) it also thinks it has a
permute and inserts a rotate in there which is also not desired.
3) So I abandoned vec-patterns and instead tried to do it in tree-vect-slp.c in
vect_analyze_slp_instance just after the SLP tree is created. Matching the SLP
tree is quite simple and getting it to emit the right SLP tree was simple
enough,
except that at this point all data references and loads have already been
calculated.
Which left me in a very painful process of removing the loads and forced me to
reconstruct all this information. But I kept hitting more and more things I
needed to manually recreate, which feels like not the right approach. If I just
add a new stmt in and leave the ones in place, it just ends up getting ignored
silently.
My guess is because this statement has no data reference to anything.
Any suggestions on what would be the right approach and that would be acceptable
for upstreaming?
Thanks,
Tamar
Re: how to build and test uClinux toolchains
On 10/16/18 7:19 AM, Christophe Lyon wrote: While reviewing one of my patches about FDPIC support for ARM, Richard raised the concern of testing the patch on other uClinux targets [1]. I looked at uclinux.org and at the GCC maintainers file, but it's still not obvious to me which uClinux targets are currently supported? You should try asking the uclinux developers. I tried looking at uclinux, and as far as I can tell, the best supported targets are arm and m68k/coldfire. crosstools-ng only supports one uclinux target for instance, which is m68k. qemu has m68k support, so you could try that. The other uclinux ports seem to be one time efforts with no long term maintenance. I see a lot of dead links on the uclinux.org site, and a lot of stuff that hasn't been updated since 2004. I see that buildroot has obvious blackfin (bfin), m68k, and xtensa uclinux support. But blackfin.uclinux.org says the uclinux port was deprecated in 2012. m68k as mentioned above should be usable. It appears that xtensa uclinux is still alive and usable. http://wiki.linux-xtensa.org/index.php/UClinux There may be other uclinux targets that are usable but don't have obvious patches to enable them. Jim
Re: [RFC][mid-end] Support vectorization of complex numbers using machine instructions.
Tamar Christina writes:
> Hi All,
>
> I am trying to add support to the auto-vectorizer for complex operations where
> a target has instructions for.
>
> The instructions I have are only available as vector instructions. The
> operations
> are complex addition with a rotation or complex fmla with a rotation for
> half floats, floats and doubles.
>
> They expect the complex number to be broken down and stored in vectors as
> real/img parts. GCC already does this first part when it lowers complex
> numbers
> very early on in tree, so that's good.
>
> As a simple example, I am trying to get GCC to emit an internal function
> .FCOMPLEX_ADD_ROT_90 (Complex addition with a 90* rotation)
> when the target supports it.
>
> my C example is:
>
> void f90 (double complex a[N], double complex b[N], double complex c[N])
> {
> for (int i=0; i < N; i++)
> c[i] = a[i] + b[i] * I;
> }
>
> Which in tree looks like
>
> _3 = a_15(D) + _2;
> _12 = REALPART_EXPR <*_3>;
> _22 = IMAGPART_EXPR <*_3>;
> _5 = b_16(D) + _2;
> _6 = IMAGPART_EXPR <*_5>;
> _8 = REALPART_EXPR <*_5>;
> _10 = c_17(D) + _2;
> _4 = _12 - _6;
> _13 = _8 + _22;
> REALPART_EXPR <*_10> = _4;
> IMAGPART_EXPR <*_10> = _13;
> [...]
> 3) So I abandoned vec-patterns and instead tried to do it in
> tree-vect-slp.c in vect_analyze_slp_instance just after the SLP tree
> is created. Matching the SLP tree is quite simple and getting it to
> emit the right SLP tree was simple enough,except that at this point
> all data references and loads have already been calculated.
(3) seems like the way to go. Can you explain in more detail why it
didn't work? The SLP tree after matching should look something like this:
REALPART_EXPR <*_10> = _4;
IMAGPART_EXPR <*_10> = _13;
_4 = .COMPLEX_ADD_ROT_90 (_12, _8)
_13 = .COMPLEX_ADD_ROT_90 (_22, _6)
_12 = REALPART_EXPR <*_3>;
_22 = IMAGPART_EXPR <*_3>;
_8 = REALPART_EXPR <*_5>;
_6 = IMAGPART_EXPR <*_5>;
The operands to the individual .COMPLEX_ADD_ROT_90s aren't the
operands that actually determine the associated scalar result, but
that's bound to be the case with something that includes an internal
permute. All we're trying to describe is an operation that does the
right thing when vectorised.
If you didn't have the .COMPLEX_ADD_ROT_90 and just fell back
on mixed two-operator SLP, the final node would be in the
opposite order:
_6 = IMAGPART_EXPR <*_5>;
_8 = REALPART_EXPR <*_5>;
So if you're doing the matching after building the initial tree,
you'd need to swap the statements in that node so that _8 comes
first and cancel the associated load permute. If you're doing the
matching on the fly while building the SLP tree then the subnodes
should start out in the right order.
Thanks,
Richard
