Seems removing that makes the configure.ac change unneeded.
Bootstrapped/regtested on x86_64-linux and i686-linux (libcc1
is built after compare, by stage3 compiler), and built
with --disable-bootstrap on i686-linux (libcc1 is built by
the system compiler in that case). Ok for trunk?
On Sat, Nov 01, 2014 at 10:23:24AM +0100, Dominique Dhumieres wrote:
Seems removing that makes the configure.ac change unneeded.
Bootstrapped/regtested on x86_64-linux and i686-linux (libcc1
is built after compare, by stage3 compiler), and built
with --disable-bootstrap on i686-linux
This is one of the patches required to make offloading via the LTO path
work when the machines involved differ.
x86 requires bigger alignments for some types than nvptx does, which
becomes an issue when reading LTO produced by the host compiler. The
problem with having a variable with
LTO has a mechanism not to stream out common nodes that are expected to
be identical on each run. When using LTO to communicate between
compilers for different targets, the va_list_type_node and related ones
must be excluded from this.
Richard B mentioned in a recent mail that the i386
This is not against current trunk; it applies to gomp-4_0-branch where
it is one of the necessary parts to make offloading x86-nvptx work. The
issue is that the LTO file format depends on the machine_modes enum, it
needs to match between host and offload target. The easiest way to do
this is
I'm sending this for reference more than anything else - this is the
patch that adds the target support for offloading to the nvptx port. It
depends on the other offloading patches Ilya is currently submitting.
I actually expect this to change a little in the near future; the nvptx
mkoffload
This patch implements support for TARGET_ATOMIC_ASSIGN_EXPAND_FENV for
powerpc*-*-linux* soft-float and e500, provided GCC is configured for
glibc 2.19 or later on the target.
New functions __atomic_feholdexcept, __atomic_feclearexcept and
__atomic_feupdateenv were added (to libc) in that glibc
When PIC register is pseudo there is nothing special about it's value
that setjmp can hurt. So if the pseudo register lives across
setjmp_receiver RA should care about correct allocation (in case it is
not saved/restored, it should go on stack). gcc.dg tests and specs
I've tested behave like this.
Good day,
I have been trying to reach you for an important issue without success. Glad I
could be able to get in touch with you today. Kindly reply as soon as possible
to get back to you in regards to why i have been trying to reach you.
Regards
Mr. David Nicodemus
On Nov 1, 2014, at 5:39 AM, Evgeny Stupachenko evstu...@gmail.com wrote:
When PIC register is pseudo there is nothing special about it's value
that setjmp can hurt. So if the pseudo register lives across
setjmp_receiver RA should care about correct allocation (in case it is
not saved/restored,
Le 1 nov. 2014 à 10:43, Jakub Jelinek ja...@redhat.com a écrit :
So you don't have libstdc++.a in
/opt/gcc/build_w/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs ?
Jakub
Indeed I have it:
[Book15] gcc/build_w% lf -l
x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs/libstdc++.a
James Greenhalgh james.greenha...@arm.com wrote:
I tried building a compiler and there were no fires, but otherwise,
I have no reasonable way to test this patch. If one of the sh
maintainers wants to pick it up and test it, that would be much
appreciated.
SH portion looks fine. No new
On 23 October 2014 12:39, Dodji Seketeli do...@redhat.com wrote:
To take this further, I am thinking that these guidelines would be even
better served by standing on their own page. If nobody objects, I can
create a DiagnosticsGuidelines page in the wiki with the content that you
added.
Subject says it all really.
Build and tested clean on x86_64-linux.
OK?
Ed
testsuite/
2014-11-02 Edward Smith-Rowland 3dw...@verizon.net
* g++.dg/cpp1y/feat-cxx11.C: Commentary and rearrangement of tests.
* g++.dg/cpp1y/feat-cxx11-neg.C: Add aggregate NSDMI test.
OK, thanks.
Jason
15 matches
Mail list logo
