Hi all,
Considering that the erratum workaround option was backported to 4.9, I
assume we'll need an item for that
in the changes.html for that branch?
The text is the same as in the trunk version that I committed recently.
Ok?
Thanks,
KyrillIndex: htdocs/gcc-4.9/changes.html
Hi all,
Considering that the erratum workaround option was backported to 4.8, I
assume we'll need an item for that
in the changes.html for that branch?
The text is the same as in the trunk version that I committed recently.
Ok?
Thanks,
KyrillIndex: htdocs/gcc-4.8/changes.html
should we also change this comment in gcc/configure?
--enable-gnu-indirect-function
enable the use of the @gnu_indirect_function to
glibc systems
So, if the patch that I sent for removing linux_has_ifunc_p is
approved, we will just add "--en
On Nov 14, 2014, at 8:38 AM, Jeff Law wrote:
> On 10/20/14 22:06, Maxim Kuvyrkov wrote:
>> Hi,
>> Ramana, this change requires benchmarking, which I can't easily do
>> at
> the moment. I would appreciate any benchmarking results that you can
> share. In particular, the value of PARAM_SCHED_AUTOPR
On 11/14/2014 03:04 PM, Martin Liška wrote:
On 11/13/2014 04:50 PM, Jan Hubicka wrote:
gcc/ChangeLog:
2014-11-12 Martin Liska
* Makefile.in: New object file is added.
* cgraph.h (symbol_table::allocate_cgraph_symbol): Summary UID
is filled up.
* cgraph_summary.c: New file.
On 11/14/2014 03:09 PM, Martin Liška wrote:
On 11/13/2014 05:04 PM, Jan Hubicka wrote:
+ if (!inline_summary_summary)
+inline_summary_summary = (inline_summary_cgraph_summary *)
inline_summary_cgraph_summary::create_ggc (symtab);
Hehe, this is funny naming scheme.
Peraps inline_summary_d
On Friday 2014-11-14 15:06, Kyrill Tkachov wrote:
> Considering that the erratum workaround option was backported to 4.8,
> I assume we'll need an item for that in the changes.html for that
> branch?
Good point.
Yes. It will be good note note which minor release is the first
with this fix, tho
Following recent vectorizer changes to reductions via shifts, AArch64 will now
reduce loops such as this
unsigned char in[8] = {1, 3, 5, 7, 9, 11, 13, 15};
int
main (unsigned char argc, char **argv)
{
unsigned char prod = 1;
/* Prevent constant propagation of the entire loop below. */
a
On Thu, 2014-11-13 at 11:45 +0100, Richard Biener wrote:
> On Thu, Nov 13, 2014 at 2:41 AM, David Malcolm wrote:
> > On Tue, 2014-11-11 at 11:43 +0100, Richard Biener wrote:
> >> On Tue, Nov 11, 2014 at 8:26 AM, Jakub Jelinek wrote:
> >> > On Mon, Nov 10, 2014 at 05:27:50PM -0500, David Malcolm w
On 11/14/2014 04:12 AM, Bernd Schmidt wrote:
- we'll need some synchronization primitives, I see atomic
support is
there, we need mutexes and semaphores I think, is that
implementable
using bar instruction?
>>>
>>> It's probably membar you need.
>>
>> That
This is the long-awaited ABI break for std::string, replacing our
venerable Copy-On-Write implementation with a C++11-conforming
Small-String-Optimization implementation (based on Paolo's vstring).
The gist of it is adding a second complete std::string implementation
that is tagged with abi_tag("
On 14 November 2014 11:38, Christophe Lyon wrote:
> On 13 November 2014 21:44, Konstantin Serebryany
> wrote:
>> On Thu, Nov 13, 2014 at 1:16 AM, Jakub Jelinek wrote:
>>> On Wed, Nov 12, 2014 at 05:35:48PM -0800, Konstantin Serebryany wrote:
Here is one more merge of libsanitizer (last one
...Patch attached...
Alan Lawrence wrote:
Following recent vectorizer changes to reductions via shifts, AArch64 will now
reduce loops such as this
unsigned char in[8] = {1, 3, 5, 7, 9, 11, 13, 15};
int
main (unsigned char argc, char **argv)
{
unsigned char prod = 1;
/* Prevent constan
On Fri, Nov 14, 2014 at 7:10 AM, Alexander Ivchenko wrote:
> should we also change this comment in gcc/configure?
>
> --enable-gnu-indirect-function
> enable the use of the @gnu_indirect_function to
> glibc systems
That will be a separate issu
On Fri, Nov 14, 2014 at 3:38 PM, H.J. Lu wrote:
> On Thu, Nov 13, 2014 at 09:32:07PM -0800, H.J. Lu wrote:
>> For i[34567]86-*-linux* and x86_64-*-linux* targets, config.gcc assumes
>> modern glibc and set default_gnu_indirect_function to yes. That is wrong
>> for i[34567]86-*-linux-android* and
Hi!
On Wed, 12 Nov 2014 11:06:26 +0100, Jakub Jelinek wrote:
> On Tue, Nov 11, 2014 at 01:53:23PM +, Julian Brown wrote:
> > [OpenACC libgomp changes]
> > [openacc.f90, and exporting symbols in libgomp.map]
> > +OACC_2.0 {
> > + global:
> > + acc_get_num_devices;
> > + acc_get_num_devic
ise linker plugin tries to compile LTO IR, which is not present.
Bootstrap and regtesting on x86_64-linux using binutils 20141114 in progress.
OK for trunk when finished?
Thanks,
-- Ilya
gcc/
* cgraphunit.c (symbol_table::compile): Set flag_fat_lto_objects
in case of g->have_of
> >
> >In a way I would like to see these to be methods of the underlying type
> >rather than
> >virtual methods of the summary, becuase these are operations on the data
> >themselves.
> >I was thinking to model these by specual constructor and copy constructor
> >(taking the extra node pointer p
Thomas,
This patches fixes this error while building the gomp-4_0-branch:
...
ref-gomp-4_0-branch-14-11-13/src/libgomp/plugin/../configure.tgt: line 30: test:
=: unary operator expected
...
The error occurs in this piece of code:
...
# Check for futex enabled all at once.
if test $enable_linux
Thomas,
while bootstrapping the gomp-4_0-branch, I ran into this error:
...
libtool: compile: build/./gcc/gfortran -Bbuild/./gcc/
-Binstall/x86_64-unknown-linux-gnu/bin/ -Binstall/x86_64-unknown-linux-gnu/lib/
-isystem install/x86_64-unknown-linux-gnu/include -isystem
install/x86_64-unknown-li
Attached is an updated version of the patch which includes
some commentary above the include of stdint.h.
Is this OK to apply?
--joel
On 11/10/2014 1:03 PM, Paolo Carlini wrote:
> Hi,
>
> On 11/10/2014 07:34 PM, Jonathan Wakely wrote:
>> On 10/11/14 12:01 -0600, Joel Sherrill wrote:
>>> cc'ing s
On Fri, Nov 14, 2014 at 07:37:49AM -0800, Cesar Philippidis wrote:
> > Hmm. It's worthwhile to keep in mind that GPU threads really behave
> > somewhat differently from CPUs (they don't really execute
> > independently); the OMP model may just be a poor match for the
> > architecture in general.
>
Hello,
Following the discussion at
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01755.html,
I am proposing this documentation patch to add more comments to some
gimple accessors for properties that are meant to be undefined at patch
boundaries. I haven't spotted all the properties in that case,
Some (very small) questions / cleanups
1) Do you plan on supporting CXX11 ABI on C++03? There is some #if
__cplusplus < 201103L inside the new basic_string.
2) Is there a need for the #if 0 _M_mutate?
I tried bootstrapping on Mac OS X 10.10, and got lots of linking
issues, the relevant part is:
Hi!
On Wed, 12 Nov 2014 11:06:26 +0100, Jakub Jelinek wrote:
> On Tue, Nov 11, 2014 at 01:53:23PM +, Julian Brown wrote:
> > @@ -1181,6 +1197,7 @@ initialize_env (void)
> >gomp_global_icv.thread_limit_var
> > = thread_limit_var > INT_MAX ? UINT_MAX : thread_limit_var;
> > }
>
On 14/11/14 10:10 -0600, Joel Sherrill wrote:
Attached is an updated version of the patch which includes
some commentary above the include of stdint.h.
Is this OK to apply?
OK, thanks.
This patch add vector pattern for __builtin_ctz.
like __builtin_clz, only 32bit version of ctz supported.
for scalar version ctz, we expand it into:
rbit
clz
reverse bits first, then turn cout tailing zero into count leading zero.
while for vector version, rbit only support byte granulari
On 11/14/2014 08:18 AM, Jakub Jelinek wrote:
>> Also, keep in mind that PTX doesn't have a global TID. The user needs to
>> calculate it using ctaid/tid and friends.
>
> Ok. Is %gridid needed for that combo too?
Eventually, probably. Currently, we're launching all of our kernels with
cuLaunchKe
On 14/11/14 16:32 +, Christopher Jefferson wrote:
Some (very small) questions / cleanups
1) Do you plan on supporting CXX11 ABI on C++03? There is some #if
__cplusplus < 201103L inside the new basic_string.
Yes, the intention is that you get the same std::string implementation
independent
On 11/14/14 04:09, Bernd Schmidt wrote:
Hi Jakub,
I have some questions about nvptx:
1) you've said that alloca isn't supported, but it seems
to be wired up and uses the %alloca documented in the PTX
manual, what is the issue with that? %alloca not being actually
implemented by the
On Fri, Nov 14, 2014 at 7:51 AM, Uros Bizjak wrote:
> On Fri, Nov 14, 2014 at 3:38 PM, H.J. Lu wrote:
>> On Thu, Nov 13, 2014 at 09:32:07PM -0800, H.J. Lu wrote:
>>> For i[34567]86-*-linux* and x86_64-*-linux* targets, config.gcc assumes
>>> modern glibc and set default_gnu_indirect_function to y
emits sections with offload IR, it should not emit "__gnu_lto_slim"
> symbol, otherwise linker plugin tries to compile LTO IR, which is not present.
>
> Bootstrap and regtesting on x86_64-linux using binutils 20141114 in progress.
> OK for trunk when finished?
>
>
This is a new version of my BE patch from a few weeks ago.
This is part 1 and covers rtlanal.c. The second part will be aarch64
specific.
When combined with the second patch, It fixes up movoi/ci/xi for Big
Endian, so that we end up with the lab of a big-endian integer to be in
the low byte of the
This is a new version of my BE patch from a few weeks ago.
This is part 2 and covers all the aarch64 changes.
When combined with the first patch, It fixes up movoi/ci/xi for Big
Endian, so that we end up with the lab of a big-endian integer to be in
the low byte of the highest-numbered register.
On Thu, Nov 13, 2014 at 8:59 PM, Jeff Law wrote:
> On 11/13/14 21:46, H.J. Lu wrote:
>
>>
>> Hi Jeff,
>>
>> I believe the patch is correct. Not all glibcs support IFUNC. It doesn't
>> mean
>> we should disable IFUNC for all glibcs. By default, we do a configure
>> time
>> check for IFUNC. We DO
Let's continue the discussion there, we can do another merge quickly
or do a cherry pick to GCC once we have a solution.
So far I don't see one. (other than not supporting the old kernels, of course)
On Fri, Nov 14, 2014 at 2:38 AM, Christophe Lyon
wrote:
> On 13 November 2014 21:44, Konstantin S
On 14/11/14 16:42 +, Jonathan Wakely wrote:
On 14/11/14 16:32 +, Christopher Jefferson wrote:
I tried bootstrapping on Mac OS X 10.10, and got lots of linking
issues, the relevant part is::
I might be missing some of the new instantiations, I'll look into
that.
I am missing some inst
On 14 Nov 08:46, H.J. Lu wrote:
> What happens when -flto is used on command line? Will we
> generate both LTO IR and offload IR?
Right.
I'm not sure whether we should make slim objects in case of LTO + offload IR...
-- Ilya
I am not sure I understand the problem,
but whatever the problem is I am against using -std=gnu++ as this will
be a different flag combination from what we have upstream.
On Fri, Nov 14, 2014 at 8:50 AM, Konstantin Serebryany
wrote:
> Let's continue the discussion there, we can do another merge q
+eugenis (what kind of testing on ARM are we doing upstream?)
On Fri, Nov 14, 2014 at 7:44 AM, Christophe Lyon
wrote:
> On 14 November 2014 11:38, Christophe Lyon wrote:
>> On 13 November 2014 21:44, Konstantin Serebryany
>> wrote:
>>> On Thu, Nov 13, 2014 at 1:16 AM, Jakub Jelinek wrote:
On 11/14/2014 10:37 AM, Jonathan Wakely wrote:
> On 14/11/14 10:10 -0600, Joel Sherrill wrote:
>> Attached is an updated version of the patch which includes
>> some commentary above the include of stdint.h.
>>
>> Is this OK to apply?
> OK, thanks.
Committed. Thanks for all the feedback.
--
Joel
On 11/14/14 04:39, Jakub Jelinek wrote:
On Fri, Nov 14, 2014 at 12:09:03PM +0100, Bernd Schmidt wrote:
I have some questions about nvptx:
1) you've said that alloca isn't supported, but it seems
to be wired up and uses the %alloca documented in the PTX
manual, what is the issue with that
> >> >
> >> > ChangeLog:
> >> >
> >> > 2014-10-30 Igor Zamyatin
> >> >
> >> > * function.c (assign_parms): Move init of pic_offset_table_rtx
> >> > from here to...
> >> > * cfgexpand.c (expand_used_vars): ...here.
> >> The patch is probably fine. However, it would be good to have th
On Fri, Nov 14, 2014 at 08:37:52AM -0800, Cesar Philippidis wrote:
> On 11/14/2014 08:18 AM, Jakub Jelinek wrote:
>
> >> Also, keep in mind that PTX doesn't have a global TID. The user needs to
> >> calculate it using ctaid/tid and friends.
> >
> > Ok. Is %gridid needed for that combo too?
>
>
On 11/14/14 04:39, Jakub Jelinek wrote:
:(. So what other option one has to implement something like TLS, even
using inline asm or similar? There is %tid, so perhaps indexing some array
with %tid? The trouble with that is that some thread can do
#pragma omp parallel again, and I bet the %tid
On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin wrote:
> On 14 Nov 08:46, H.J. Lu wrote:
>> What happens when -flto is used on command line? Will we
>> generate both LTO IR and offload IR?
>
> Right.
>
> I'm not sure whether we should make slim objects in case of LTO + offload
> IR...
>
Isn't __gn
On Fri, Nov 14, 2014 at 12:50 AM, Tejas Belagod wrote:
> On 14/11/14 08:19, Andrew Pinski wrote:
>>
>> On Fri, Nov 14, 2014 at 12:12 AM, Tejas Belagod
>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> Following the discussion here
>>> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02237.html, this has been
>>> tr
On Fri, Nov 14, 2014 at 8:59 AM, Zamyatin, Igor wrote:
>> >> >
>> >> > ChangeLog:
>> >> >
>> >> > 2014-10-30 Igor Zamyatin
>> >> >
>> >> > * function.c (assign_parms): Move init of pic_offset_table_rtx
>> >> > from here to...
>> >> > * cfgexpand.c (expand_used_vars): ...here.
>> >>
On 11/14/14 05:36, Jakub Jelinek wrote:
So, for a warp, if some threads perform one branch of an if and other
threads another one, all threads perform the first one first (with some
maybe not doing anything), then all the threads the others (again, other
threads not doing anything)?
Nobody ever
> On Fri, Nov 14, 2014 at 8:59 AM, Zamyatin, Igor
> wrote:
> >> >> >
> >> >> > ChangeLog:
> >> >> >
> >> >> > 2014-10-30 Igor Zamyatin
> >> >> >
> >> >> > * function.c (assign_parms): Move init of pic_offset_table_rtx
> >> >> > from here to...
> >> >> > * cfgexpand.c (expand_used_
Hi,
On Fri, Nov 14, 2014 at 04:23:41PM +0100, Martin Liska wrote:
> Patch v3.
>
> Martin
> From 7255ffaf7bb416037baa14499b197bac3be8c222 Mon Sep 17 00:00:00 2001
> From: mliska
> Date: Fri, 14 Nov 2014 16:14:28 +0100
> Subject: [PATCH 2/3] First usage of cgraph_summary in ipa-prop pass.
>
> gc
On 14 Nov 09:01, H.J. Lu wrote:
> On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin wrote:
> > On 14 Nov 08:46, H.J. Lu wrote:
> >> What happens when -flto is used on command line? Will we
> >> generate both LTO IR and offload IR?
> >
> > Right.
> >
> > I'm not sure whether we should make slim objects
On 11/14/14 03:57, Richard Biener wrote:
I think we should simply discourage people from using sstream for
example.
I can live with that -- I've seen sstream stuff fly by in a few places,
almost asked the submitters to remove it (I find the style of coding
most folks use with sstream horrid t
Thank you for the quick reply.
> Please repost after updating to test HAVE_prologue and HAVE_epilogue and
> adding a testcase.
I have managed to reproduce the problem on the small test case on mips32, but
the test is architecture independent and should probably fail on many other
ports without
On Fri, Nov 14, 2014 at 05:05:57PM +, Zamyatin, Igor wrote:
> > > --- /dev/null
> > > +++ b/gcc/testsuite/gcc.target/i386/pr63845.c
> > > @@ -0,0 +1,20 @@
> > > +/* PR sanitizer/63845 */
> > > +/* { dg-do compile } */
> > > +/* { dg-require-effective-target ia32 } */
> > > +/* { dg-require-effe
On Fri, Nov 14, 2014 at 9:08 AM, Ilya Verbin wrote:
> On 14 Nov 09:01, H.J. Lu wrote:
>> On Fri, Nov 14, 2014 at 8:51 AM, Ilya Verbin wrote:
>> > On 14 Nov 08:46, H.J. Lu wrote:
>> >> What happens when -flto is used on command line? Will we
>> >> generate both LTO IR and offload IR?
>> >
>> > Ri
Hi Tobias,
Does printf work? I thought I/O is not supported? Or does it just accept
it for linking and drop it? I think Janne's patch has already dealt with
the issue of stack allocation.
printf (or more accurately vprintf) is supported by ptx as a magic
builtin function. We have a printf wra
On 11/14/14 03:44, Eric Botcazou wrote:
I wonder how many other problems of this nature are lurking in reorg.c.
For example steal_delay_list_from_{target,fallthrough} or the code
which searches for arithmetic at the branch target, and puts the
opposite insn in a delay slot.
Right, and the latte
On Fri, Nov 14, 2014 at 03:48:22PM +0100, Andrew Burgess wrote:
> * Jakub Jelinek [2014-11-13 14:13:42 +0100]:
>
> > On Thu, Nov 13, 2014 at 01:21:21PM +0100, Andrew Burgess wrote:
> > > I had a look around and couldn't find anything helpful. The best I
> > > can offer would be the current path
After recent updates, tree-vect-loop.c is in the same state as when this cleanup
patch was first written and approved, so I've just pushed it as r/217580.
Cheers,
Alan
Richard Biener wrote:
On Thu, Sep 18, 2014 at 2:48 PM, Alan Lawrence wrote:
Following earlier patches, vect_create_epilog_fo
Hi,
This patch introduces a simple library with several wrappers to be used with
MPX and Pointer Bounds Checker. Wrappers allow to obtain, copy and just keep
alive bounds whrough widely use library calls. It significantly increases
checking quality.
Thanks,
Ilya
--
gcc/
2014-11-14 Ilya En
On Fri, Nov 14, 2014 at 01:06:52PM +0100, Dodji Seketeli wrote:
> Jakub Jelinek writes:
>
> >> I am not sure, but I am wondering if we shouldn't save the previous uid
> >> of 'stmt' here before setting it, and then restore it before getting out
> >> of this function.
> >
> > No, gimple uids are A
> On Fri, Nov 14, 2014 at 05:05:57PM +, Zamyatin, Igor wrote:
>
> It is not that easy, -fsanitize=address is not supported everywhere.
> Better if you stick it into testsuite/gcc.dg/asan/ No point adding effective-
> target ia32/fpic, there is nothing i?86 specific, not even ix86/x86_64
> sp
Hi,
This patch adds wrapper calls. It's simply achieved by using proper name for
builtin clones. Patches apply over builtins instrumentation series.
Thanks,
Ilya
--
2014-11-14 Ilya Enkovich
* c-family/c.opt (fchkp-use-wrappers): New.
* ipa-chkp.c (CHKP_WRAPPER_SYMBOL_PREFIX
On 11/13/14 15:59, Mike Stump wrote:
The problem, since this is a hook now, one can’t just test ifdef
FUNCTION_PROLOGUE.
Right, but we can test the existence of the expander via the HAVE_xxx
interface.
What that can't test is the expander failing (via FAIL;). But the
prologue/epilogue expand
On Fri, Nov 14, 2014 at 12:01:43PM +0100, Richard Biener wrote:
> > doc/invoke.texi also talks about it, wonder if it shouldn't be mentioned
> > elsewhere, install.texi?
>
> Sure - the configure option should be mentioned in install.texi as well.
Here it is. Ok for trunk?
2014-11-14 Jakub Jeli
Hi,
Here are few tests for MPX wrappers. Will add more in case patches #1,2 are OK.
Thanks,
Ilya
--
2014-11-14 Ilya Enkovich
* lib/mpx-dg.exp (mpx_link_flags): Set path to wrappers library.
* gcc.target/i386/mpx/calloc-1-lbv.c: New.
* gcc.target/i386/mpx/calloc-1-ubv.
On 14 November 2014 08:12, Tejas Belagod wrote:
> 2014-11-14 Tejas Belagod
>
> gcc/
> * config/aarch64/aarch64-protos.h (aarch64_classify_symbol):
> Fixup prototype.
> * config/aarch64/aarch64.c (aarch64_expand_mov_immediate,
> aarch64_cannot_force_const_mem, aa
Hi!
When looking at PR59984, I've noticed that in certain cases we leave
around GOMP_SIMD_LANE calls without lhs.
This internal call is intentionally not ECF_CONST, we don't want it moved
before the loop, and the argument is magic. But, if nothing uses it
anymore, it isn't needed.
Fixed thusly,
On Thu, Nov 13, 2014 at 12:52:21PM +0100, Jakub Jelinek wrote:
> On Thu, Nov 13, 2014 at 09:39:42AM +0100, Jakub Jelinek wrote:
> > What about the:
> > > > I wonder if the nonfreeing_call_p function shouldn't be moved elsewhere
> > > > though (suggestion where), so that gimple.c doesn't need the cg
> On Thu, Nov 13, 2014 at 12:52:21PM +0100, Jakub Jelinek wrote:
> > On Thu, Nov 13, 2014 at 09:39:42AM +0100, Jakub Jelinek wrote:
> > > What about the:
> > > > > I wonder if the nonfreeing_call_p function shouldn't be moved
> > > > > elsewhere
> > > > > though (suggestion where), so that gimple.
On 11/14/14 08:12, Maxim Kuvyrkov wrote:
...
Can this be built on top of Bin's work for insn fusion? There's a
lot of commonality in the structure of the insns you care about.
He's already got a nice little priority function that I think you
could utilize to to ensure the insns with smaller off
On 11/14/14 10:33, Jakub Jelinek wrote:
Hi!
When looking at PR59984, I've noticed that in certain cases we leave
around GOMP_SIMD_LANE calls without lhs.
This internal call is intentionally not ECF_CONST, we don't want it moved
before the loop, and the argument is magic. But, if nothing uses it
On 11/14/14 03:34, Richard Biener wrote:
Well - we do have that scary TODO_do_not_ggc_collect. It would be
nice to be able to call protect_gc () from ira.c and unprotect_gc ()
from the reload/lra pass and get rid of that TODO.
Yea, can't argue with that.
And yes, a ggc_collect () should be
On Nov 14, 2014, at 9:30 AM, Jeff Law wrote:
> On 11/13/14 15:59, Mike Stump wrote:
>>
>> The problem, since this is a hook now, one can’t just test ifdef
>> FUNCTION_PROLOGUE.
> Right, but we can test the existence of the expander via the HAVE_xxx
> interface.
Which ones, HAVE_prologue?
On 11/14/14 10:31, Jakub Jelinek wrote:
On Fri, Nov 14, 2014 at 12:01:43PM +0100, Richard Biener wrote:
doc/invoke.texi also talks about it, wonder if it shouldn't be mentioned
elsewhere, install.texi?
Sure - the configure option should be mentioned in install.texi as well.
Here it is. Ok f
We ICEd when dumping the IPA symbol table when -fsanitize=undefined
and -fdump-ipa-* options were enabled on every testcase where we
sanitized something and thus internal ubsan data have been created.
The problem was that the C++ printer expects a decl as a TYPE_NAME,
but we were sticking an identi
On Nov 14, 2014, at 9:51 AM, Mike Stump wrote:
> On Nov 14, 2014, at 9:30 AM, Jeff Law wrote:
>> On 11/13/14 15:59, Mike Stump wrote:
>>>
>>> The problem, since this is a hook now, one can’t just test ifdef
>>> FUNCTION_PROLOGUE.
>> Right, but we can test the existence of the expander via the HA
> Hi,
>
> this patch removes now completely unnecessary KNOWN_TYPE jump
> functions, type_preserved fields from PASS_THROUGH and ANCESTOR jump
> functions and type field from ANCESTOR jump functions because the
> previous patch makes them unused.
>
> This means most of dynamic type change detecti
This patch from Peter Collingbourne installs libgo under a different
name when it is built using llgo. Bootstrapped and ran Go testsuite
on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r ed47faa83681 libgo/Makefile.am
--- a/libgo/Makefile.am Wed Nov 12 16:07:28 2014 -0800
+++ b/lib
On Fri, Nov 14, 2014 at 05:06:44PM +0100, Jan Hubicka wrote:
> > >
> > >In a way I would like to see these to be methods of the underlying type
> > >rather than
> > >virtual methods of the summary, becuase these are operations on the data
> > >themselves.
> > >I was thinking to model these by spe
On Fri, 2014-11-14 01:37:14 +0100, Jan Hubicka wrote:
> Hi,
> here is upated version with bitfields and also tested on PPC64-linux/aix.
> I hacked configury to use system awk instead of gawk, so the changes are
> hopefully safe.
>
> OK?
> Honza
>
> * optc-save-gen.awk: Output cl_target_op
On 14 November 2014 13:18, Jakub Jelinek wrote:
> Indeed, it does. So feel free to turn that into patch form.
This is what I committed. I also updated the Fortran part to add an
example and remove outdated info. Feel free to change it (or ask me to
change it).
--- htdocs/gcc-5/changes.html 14
On Fri, 14 Nov 2014, Jakub Jelinek wrote:
> You want
> gfc_error (is_oacc (p)
> ? "%s statement at %C leaving OpenACC structured block"
> : "%s statement at %C leaving OpenMP structured block",
> gfc_ascii_statement (st));
> instead to be mo
On Fri, 14 Nov 2014, Jakub Jelinek wrote:
> On Fri, Nov 14, 2014 at 09:46:14AM +0300, Yury Gribov wrote:
> > Hi all,
> >
> > This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63802 by only
> > limiting minimal type alignment with BIGGEST_ALIGNMENT for types with no
> > __attribute__((
The situation with debugging on ptx is a little strange - it allows
.file and .loc directives for line numbers, and it provides a way to
define dwarf2 debug sections - but as far as I can tell, there's no way
of putting useful or accurate information into the latter. There's also
the slight pro
On 11/05/2014 01:19 AM, Bernd Schmidt wrote:
On 11/04/2014 10:50 PM, Jeff Law wrote:
No, I don't think it's terminology. It's really that in effect we have
two targets. One is a normal CPU, the other is a GPU.
ie, there's nothing that says we won't have a GPU that's being driven by
an ARM or
On 11/03/2014 11:23 PM, Jeff Law wrote:
On 11/01/14 05:51, Bernd Schmidt wrote:
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
On 11/05/2014 12:17 AM, Jeff Law wrote:
On 11/04/14 14:08, Bernd Schmidt wrote:
On 11/04/2014 10:01 PM, Jeff Law wrote:
Communication between host and GPU is all done via some form of memcpy,
so I wouldn't expect this to be a problem.
They still need to agree on the layout of the structure.
On Sun, Sep 1, 2013 at 6:57 AM, Jan Hubicka wrote:
> Hi,
> this patch implement speculative devirtualization. It is a trivial pass that
> asks for targets of every polymorphic call in a program and if the list
> contains one likely target, it produces an speculative call. No context
> sensitive a
>
> Breaks build:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
> -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overl
On Fri, 14 Nov 2014, Ilya Enkovich wrote:
> Hi,
>
> This patch introduces a simple library with several wrappers to be used
> with MPX and Pointer Bounds Checker. Wrappers allow to obtain, copy and
> just keep alive bounds whrough widely use library calls. It
> significantly increases checki
On Fri, 14 Nov 2014, Ilya Enkovich wrote:
> * c-family/c.opt (fchkp-use-wrappers): New.
Command-line options need documenting in invoke.texi.
--
Joseph S. Myers
jos...@codesourcery.com
Hi,
this patch kills lto's code to rebuilt DECL_FUNCTION_SPECIFIC_TARGET from target
attributes. This code was never complete and it should be no-op now when we
save
tehe target nodes.
It also makes free_land_data_in_decl to actually anotate all function bodies
with
a default option node. The r
Here are five patches that together allow combine to do more useful
work with PARALLELs of two SETs, like on many machines a set of a GPR
and one of the condition code, or a GPR and the carry bit on PowerPC,
or two GPRs on some machines.
The first patch is just for debug.
The second is the real m
Output the cost calculation always, not only when the costs disallow
a combination. Checking if your port has sane costs is much easier
this way.
Also there is no point in printing full lines at once; debug dumps
are never translated, so we can print piece by piece.
2014-11-14 Segher Boessenko
On 11/13/2014 02:32 AM, Janne Blomqvist wrote:
> in the spirit of PR 60324 and 61035, here's a patch that gets rid of
> the remaining potentially unbounded stack allocations in libgfortran.
> All uses of __builtin_alloca() and VLA's are replaced either straight
> with heap allocated memory, or wit
If I2 is a PARALLEL of two SETs, split it into two instructions, I1
and I2. If there already was an I1, rename it to I0. If there
already was an I0, don't do anything.
This surprisingly simple patch is enough to let combine handle such
PARALLELs properly.
2014-11-14 Segher Boessenkool
gcc/
With this new field in place, we can have LOG_LINKS for insns that set
more than one register and distribute them properly in distribute_links.
This then allows many more PARALLELs to be combined.
Also split off new functions can_combine_{def,use}_p from the
create_log_links function.
2014-11-14
Now that LOG_LINKS are per regno, we can distribute them on PARALLELs
just fine. Do so. This makes PARALLELs not lose their LOG_LINKS early
when e.g. a trivial reg-reg move is combined, so that they can be used
in more useful combinations as well.
2014-11-14 Segher Boessenkool
gcc/
101 - 200 of 250 matches
Mail list logo
