A Christmas gift to the m68k folks (or how an older box in the basement
has spent the last 3 weeks).
Essentially this BZ is a request to turn certain inequality comparisons
against small integers (2^n - 1 for small n) into right shifts then a
test of the Z bit.
So for example a <= 3 (give
It's indeed fixed now. Thanks.
Best regards,
Thomas
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Christian Bruel
> Sent: Wednesday, December 09, 2015 6:13 PM
> To: gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH, testsuit
On Jan 19, 2016, at 7:50 PM, Nguyễn Sinh Ngọc
wrote:
> How can I post it into gcc-patches for everyone reviewing?
Just send an email with it. If too large for a single email, you can compress
it. If still too large, you can drop it on a server and just post a link to
the file.
As discussed at https://gcc.gnu.org/ml/gcc/2016-01/msg00023.html , the
Go frontend needs some way to prevent ivopts from temporarily removing
all pointers into a memory block. This patch adds a new option
-fcollectible-pointers which makes that happen. This is not the best
way to solve the proble
Compile-time MPX tests don't need the MPX run-time library. They
should pass for non-x32 target.
OK for trunk and backport to GCC 5 branch?
H.J.
---
Compile-time MPX tests don't need the MPX run-time library. They
should pass for non-x32 target.
PR testsuite/69369
* g++.dg/pr63
I thought it was odd to see numerous references to "DWARF 2" in the
manual and statements like "This option only works for DWARF 2", when
GCC is now emitting DWARF version 4 by default. As far as I can tell
from browsing dwarf2out.c, the options documented for "DWARF 2" actually
do apply to al
Dear all,
I have developed a new port for microcontroller 8bit.
How can I post it into gcc-patches for everyone reviewing?
I don't have the account on gcc.gnu.org which have the privileged to
post it to gcc-patches by git.
How can I register a new account?
--
Thanks & Best regards
Nguyễn Sinh N
On Tue, 19 Jan 2016, Patrick Palka wrote:
On Mon, Jan 18, 2016 at 4:04 PM, Jason Merrill wrote:
On 01/18/2016 02:12 PM, Patrick Palka wrote:
On Mon, Jan 18, 2016 at 10:34 AM, Jason Merrill wrote:
On 12/25/2015 12:37 PM, Patrick Palka wrote:
That alone would not be sufficient because mo
On 01/19/2016 08:45 AM, Jan Hubicka wrote:
Hi,
this patch mentiones few user visible changes I can think of. I will
add some quality data on firefox once stage3 closes.
It seems that the optimization section of changes.html deserve some work :)
Honza
Index: changes.html
==
On Mon, 2016-01-11 at 21:35 +, Bernd Edlinger wrote:
> Could if work also if you set native_system_header_dir to
> /opt/$with_advance_toolchain/include or somthing and instead of
> -isystem $at/include in INCLUDE_EXTRA_SPEC you could add something like
> %{!nostdinc:-idirafter $original_native_
On 01/19/2016 03:24 AM, Ilya Enkovich wrote:
2016-01-19 5:25 GMT+03:00 Sandra Loosemore :
I think the documentation relating to '-z bndplt' in the GCC manual
description of -fcheck-pointer-bounds is incorrect. It looks like, as of
r225862, the GCC driver is supposed to emit an error message if
This fixes this warning:
/home/jwakely/src/gcc/gcc/doc/invoke.texi:501: warning: `.' or `,' must follow
@xref
Committed as obvious.
commit 2a609eb7f91281eab9a234dfcf0c53c7d3013ddb
Author: Jonathan Wakely
Date: Wed Jan 20 00:24:58 2016 +
* doc/invoke.texi (Options Summary): Add '.
On Wed, Jan 20, 2016 at 12:40:08AM +0100, Jakub Jelinek wrote:
> On Wed, Jan 20, 2016 at 12:17:36AM +0100, Gerald Pfeifer wrote:
> > On Tue, 19 Jan 2016, Jakub Jelinek wrote:
> > > Note, we want to tweak gcc-{4.9,5}/changes.html too, and
> > > there are more colors than just red in there.
> >
> >
On Wed, Jan 20, 2016 at 12:17:36AM +0100, Gerald Pfeifer wrote:
> On Tue, 19 Jan 2016, Jakub Jelinek wrote:
> > Note, we want to tweak gcc-{4.9,5}/changes.html too, and
> > there are more colors than just red in there.
>
> Yes, I just got tired and need to log off now.
>
> > Also, seems the colo
On Tue, Jan 19, 2016 at 4:16 AM, Jan Hubicka wrote:
> Hi,
> this patch makes the code turning instrumentation thunks into transparent
> aliases to work.
>
> Bootstrapped/regtested x86_64-linux, will commit it later today.
>
> Honza
>
> * cgraphunit.c (cgraph_node::reset): Clear thunk info
On Tue, 19 Jan 2016, Jakub Jelinek wrote:
> Note, we want to tweak gcc-{4.9,5}/changes.html too, and
> there are more colors than just red in there.
Yes, I just got tired and need to log off now.
> Also, seems the colors disappeared also from e.g.
> https://gcc.gnu.org/projects/cxx1z.html
Lovel
There's no point in walking through the PHIs to trace values for
SSA_NAMEs that appear in abnormal PHIs -- we're not supposed to be
threading those paths to begin with.
This happens to avoid a lot of useless work for BZ 69347.
Bootstrapped and regression tested on x86. Committed to the trun
On Tue, Jan 19, 2016 at 11:49:27PM +0100, Gerald Pfeifer wrote:
> On Tue, 19 Jan 2016, Jakub Jelinek wrote:
> > Perhaps we need to use something other than ...
> > and similar, the question is what. It certainly worked well back almost 3
> > years ago when I've added those into gcc-4.9/changes.htm
On Tue, 19 Jan 2016, Jakub Jelinek wrote:
> Perhaps we need to use something other than ...
> and similar, the question is what. It certainly worked well back almost 3
> years ago when I've added those into gcc-4.9/changes.html.
And interestingly it still does when I download the page and view
it
This fixes warnings like this from gawk due to using an empty string
as the third argument:
gawk: cmd. line:9: (FILENAME=mytest.ii FNR=4) warning: gensub: third argument
`' treated as 1
Committed as obvious.
commit 6ba6e37c3bfe88347a3b3e3069814c4d056bd469
Author: Jonathan Wakely
Date: Tue J
On Jan 19, 2016, at 12:52 PM, Sandra Loosemore wrote:
> I've checked in this patch to address some copy-editing issues
I glanced around at it, looks nice, thanks.
On 08/01/16 19:18 +, Jonathan Wakely wrote:
This resolves the longstanding issue that #include uses the C
library header, which on most targets doesn't declare the additional
overloads required by C++11 26.8 [c.math], and similarly for
.
With this patch libstdc++ provides its own and
wrap
On 01/15/2016 09:58 AM, Bernd Schmidt wrote:
PR43052 is a PR complaining about how the rep cmpsb expansion that gcc
uses for memcmp is slower than the library function. As is so often the
case, if you investigate a bit, you can find a lot of issues with the
current situation in the compiler.
Thi
On Mon, Jan 18, 2016 at 4:04 PM, Jason Merrill wrote:
> On 01/18/2016 02:12 PM, Patrick Palka wrote:
>>
>> On Mon, Jan 18, 2016 at 10:34 AM, Jason Merrill wrote:
>>>
>>> On 12/25/2015 12:37 PM, Patrick Palka wrote:
That alone would not be sufficient because more_specialized_fn()
>>
I've checked in this patch to address some copy-editing issues I noticed
when I was working on re-ordering the content of invoke.texi last week.
This is pretty boring content-free stuff, for the most part -- markup,
hyphenation issues, typos, etc. I had also noticed that the
standards.texi do
There were a couple of ways that libgccjit could fail to unlink all
of its tempfiles, leading to /tmp/libgccjit-* tempdirs lingering
after the build:
- dumpfiles requested by gcc_jit_context_enable_dump
- ahead-of-time compilation artifacts which lingered in the tempdir
after they've been copied
> On Jan 19, 2016, at 6:41 AM, Jakub Jelinek wrote:
> > But then perhaps it will be better incentive for the projects to fix their
> > cruft. With a specialized option they will keep broken code forever.
>
> Flags are forever.
OK, in https://gcc.gnu.org/ml/gcc-patches/2016-01/msg01435.html I in
On 01/19/2016 10:05 PM, Manuel López-Ibáñez wrote:
> Am I the only one who doesn't see the colors at
> https://gcc.gnu.org/gcc-6/changes.html#c-family nor
> https://gcc.gnu.org/gcc-5/changes.html#fortran ?
>
> Firefox 43.0.4 says "Content Security Policy: The page's settings blocked the
> loading
On Tue, Jan 19, 2016 at 07:42:53PM +, Manuel López-Ibáñez wrote:
> On 19 January 2016 at 19:31, Mike Stump wrote:
> > On Jan 19, 2016, at 11:05 AM, Manuel López-Ibáñez
> > wrote:
> >>
> >> Am I the only one who doesn't see the colors at
> >> https://gcc.gnu.org/gcc-6/changes.html#c-family n
I missed dead code when I removed the cacheline stuff.
local_type_traits hasn't been updated either, apparently leading to
bootstrap issues. So we just remove more dead code.
Tested fine on x86_64-linux. Committed.
commit c608b69c3c49c7d29033faf328fd4d117f31fd9f
Author: Torvald Riegel
Date: T
Recently on IRC we've concluded that for GCC 5 the simplest solution
will be to just disable the problematic pattern on GENERIC. So done
in the following. (The problem was that the match.pd pattern created
SAVE_EXPRs which then leaked into gimplification.)
Bootstrapped/regtested on x86_64-linux,
On 19 January 2016 at 19:31, Mike Stump wrote:
> On Jan 19, 2016, at 11:05 AM, Manuel López-Ibáñez
> wrote:
>>
>> Am I the only one who doesn't see the colors at
>> https://gcc.gnu.org/gcc-6/changes.html#c-family nor
>> https://gcc.gnu.org/gcc-5/changes.html#fortran ?
>
> Yes. The darkslategr
On Jan 19, 2016, at 11:05 AM, Manuel López-Ibáñez wrote:
>
> Am I the only one who doesn't see the colors at
> https://gcc.gnu.org/gcc-6/changes.html#c-family nor
> https://gcc.gnu.org/gcc-5/changes.html#fortran ?
Yes. The darkslategrey of the headings is very close to black, but the links
s
On 19/01/16 20:10 +0100, Torvald Riegel wrote:
On Sat, 2016-01-16 at 10:57 +0100, Dominique d'Humières wrote:
> Addressed these, fixed a problem with using GLIBCXX_WEAK_DEFINITION
> (which is only set on Darwin despite the generic-sounding name -- so
> just use __attribute__((weak)) directly), a
On Sat, 2016-01-16 at 10:57 +0100, Dominique d'Humières wrote:
> > Addressed these, fixed a problem with using GLIBCXX_WEAK_DEFINITION
> > (which is only set on Darwin despite the generic-sounding name -- so
> > just use __attribute__((weak)) directly), and also updated
> > testsuite_abi.cc so that
On 19/01/16 17:08, Gerald Pfeifer wrote:
On Fri, 15 Jan 2016, David Malcolm wrote:
Here's an updated version of the above, which the W3C validator
reports as being clean (fixing various "&" and "<" and a missing
end-tag).
Nice - and a lot of nice changes you implemented since GCC 5!
Am I th
On 01/18/2016 08:55 PM, Toon Moene wrote:
On 01/17/2016 01:44 PM, Thomas Koenig wrote:
So... comments? Toon, would this help you? Could yo maybe give this
a spin?
Thanks, the nightly test at my home computer will build with your patch.
That was the plan; unfortunately, the system crashed
The comment removed by this patch asserts that we can't see a VAR_DECL
in unify, because any use of a variable as a template argument will have
been adjusted to be either its constant value or its address. But that
isn't actually true when the type of the non-type template parameter
depends on
On Jan 19, 2016, at 6:41 AM, Jakub Jelinek wrote:
> But then perhaps it will be better incentive for the projects to fix their
> cruft. With a specialized option they will keep broken code forever.
Flags are forever.
H.J. Lu wrote:
> It breaks bootstrap on Linux/x86:
Committed trivial fix as r232576:
Index: gcc/ChangeLog
===
--- gcc/ChangeLog(revision 232575)
+++ gcc/ChangeLog(working copy)
@@ -1,3 +1,7 @@
+2016-01-19 Wilco Dijkstra
+
Attached is the patch to avoid the ICE that Kai posted below
with the test case Marek asked for in his response. I didn't
see any further followup on the list.
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02325.html
Martin
gcc/testsuite/ChangeLog:
2016-01-19 Martin Sebor
PR c++/59759
*
Hi,
I've prepared a new patch based on the received review (attached). I also added
a mod on invoke.texi regarding mll64 documentation. This mod was missing in the
first patch.
I have tested it with dg.exp for arc700, archs and archs+ll64.
Please let me know if everything is alright.
Thank yo
On Fri, 15 Jan 2016, David Malcolm wrote:
> Here's an updated version of the above, which the W3C validator
> reports as being clean (fixing various "&" and "<" and a missing
> end-tag).
Nice - and a lot of nice changes you implemented since GCC 5!
> OK to commit?
Yep. I was going to flag "miss
On Tue, Jan 19, 2016 at 06:28:18AM +0100, Roger Ferrer Ibáñez wrote:
> Hi,
>
> aarch64-builtins.c defines several SIMD builtin types. Among these
> SIMD types there are the polynomials __Poly{8,16,64,128}_t. These are
> built by a call to build_distinct_type_copy
> (unsigned_int{Q,H,D,T}I_type_nod
On 01/19/2016 05:50 PM, Jan Hubicka wrote:
+static bool
+is_cxa_pure_virtual_p (tree target)
+{
+ return target && TREE_CODE (TREE_TYPE (target)) != METHOD_TYPE
+&& DECL_NAME (target)
+&& !strcmp (IDENTIFIER_POINTER (DECL_NAME (target)),
+"__cxa_pure_virtual"
On 01/19/2016 03:56 AM, Kugan wrote:
Hi,
lto.texi has "Currently, the linker plugin works only in combination
with the Gold linker, but a GNU ld implementation is under development".
I don't think this is true any more. Attached patch removes this. is
this OK for trunk?
Thanks,
Kugan
gcc/Chang
Hi,
currently we optimize calls to pure virtual functions to __builtin_unreachable.
While this is correct it does make code harder to debug. This patch makes
ipa-devirt to treat cxa_pure_virtual specially and devirtualize to it when
it is the only posible target.
Bootstrapped/regtested x86_64-lin
H.J. Lu wrote:
> It breaks bootstrap on Linux/x86:
Sorry about that - it looks like the warning levels seem to have changed since
that patch was tested...
I have a trivial fix which I'll get checked in soon.
Wilco
Patch for the /projects/cxx1z.html page to document the unary
static_assert in C++17.
Committed to CVS.
Index: htdocs/projects/cxx1z.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/projects/cxx1z.html,v
retrieving revision 1.8
diff -u -r1
Hi,
this patch mentiones few user visible changes I can think of. I will
add some quality data on firefox once stage3 closes.
It seems that the optimization section of changes.html deserve some work :)
Honza
Index: changes.html
===
On Tue, Dec 15, 2015 at 2:33 AM, Wilco Dijkstra wrote:
> ping
>
>> -Original Message-
>> From: Wilco Dijkstra [mailto:wilco.dijks...@arm.com]
>> Sent: 13 November 2015 16:03
>> To: 'gcc-patches@gcc.gnu.org'
>> Subject: [PATCH 4/4][AArch64] Cost CCMP instruction sequences to choose
>> bett
This documents Ed's recent addition to trunk.
Committed to cvs.
Index: htdocs/gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.46
diff -u -r1.46 changes.html
--- htdocs/gcc-6/changes
On Tue, Jan 19, 2016 at 9:56 AM, Jason Merrill wrote:
> On 01/18/2016 10:55 PM, Patrick Palka wrote:
>>
>> mark_used is wrongly diagnosing a use of a TEMPLATE_DECL (e.g. the call
>> to f1 in function f3 of auto-fn29.C below) for having an undeduced
>> 'auto' return type. This doesn't make sense,
On 16/01/16 14:49, Senthil Kumar Selvaraj wrote:
User-agent: mu4e 0.9.13; emacs 24.5.1
Hi,
Apologies for the bad posting style (I don't have the
original email handy), but shouldn't _gnu_cmse_nonsecure_call be defined
with the .global directive in the below hunk (to make it visible when linking
On Sat, 12 Dec 2015, Matthew Fortune wrote:
> > > * config/mips/mips.c (mips_promote_function_mode): New function.
> > > (TARGET_PROMOTE_FUNCTION_MODE): Define as above function.
> > > (TARGET_PROMOTE_PROTOTYPES): Remove.
>
> I'm OK with this change on the basis that MIPS has been providing
On Tue, Jan 19, 2016 at 4:13 PM, Christian Bruel wrote:
>
>
> On 01/19/2016 04:01 PM, Christian Bruel wrote:
>>
>> Hi Richard,
>>
>> thanks for your input,
>>
>> On 01/18/2016 12:36 PM, Richard Biener wrote:
>>>
>>> On Fri, Jan 8, 2016 at 2:29 PM, Christian Bruel
>>> wrote:
When compili
On 19/01/16 14:21, Ramana Radhakrishnan wrote:
On Fri, Jan 15, 2016 at 3:05 PM, Kyrill Tkachov
wrote:
Hi all,
In this PR the ARMv8 vcvt instructions end up being conditionalised when
they don't have a conditional form.
setting the predicable attribute to "no" is not enough. We need to set the
On Tue, 19 Jan 2016, Thomas Schwinge wrote:
> Hi!
>
> On Tue, 19 Jan 2016 17:07:17 +0300, Alexander Monakov
> wrote:
> > On Tue, 19 Jan 2016, Alexander Monakov wrote:
> > > > ... to determine an optimal number of threads per block given the number
> > > > of registers (maybe just querying
> >
On Tue, 19 Jan 2016, Jakub Jelinek wrote:
> On Tue, Jan 19, 2016 at 03:19:17PM +0100, Richard Biener wrote:
> >
> > It also seems we're wrongly using values defined for the host while
> > looking at GIMPLE IL for the target.
> >
> > Bootstrap / regtest running on x86_64-unknown-linux-gnu.
> >
>
On 01/05/2016 04:30 AM, Eric Botcazou wrote:
It doesn't look to me like DW_AT_endianity is applicable to array types
or members in DWARF 3/4; instead, it should be applied to the underlying
base type.
OK, the attached patch does that so is more invasive as expected.
Please document the revers
On 01/18/2016 10:55 PM, Patrick Palka wrote:
mark_used is wrongly diagnosing a use of a TEMPLATE_DECL (e.g. the call
to f1 in function f3 of auto-fn29.C below) for having an undeduced
'auto' return type. This doesn't make sense, because an 'auto' used
inside a template doesn't get deduced until
Hi!
On Tue, 19 Jan 2016 17:07:17 +0300, Alexander Monakov
wrote:
> On Tue, 19 Jan 2016, Alexander Monakov wrote:
> > > ... to determine an optimal number of threads per block given the number
> > > of registers (maybe just querying CU_FUNC_ATTRIBUTE_MAX_THREADS_PER_BLOCK
> > > would do that alre
On 19/01/16 11:15, Christophe Lyon wrote:
For neon_vdupn, I chose to implement neon_vdup_nv4hf and
neon_vdup_nv8hf instead of updating the VX iterator because I thought
it was not desirable to impact neon_vrev32.
Well, the same instruction will suffice for vrev32'ing vectors of HF just as
well
On Tue, Jan 19, 2016 at 03:37:02PM +0100, Markus Trippelsdorf wrote:
> > Agreed. As we already have a flag that can be used as a workaround I don't
> > see
> > a reason to add another more specific one. That just makes it a
> > lesser incentive
> > for people to fix their code.
>
> Well, -fno-d
Hi!
On Tue, 19 Jan 2016 08:47:02 -0500, Nathan Sidwell wrote:
> On 01/19/16 06:49, Thomas Schwinge wrote:
> > int axis = get_oacc_ifn_dim_arg (call);
> > + if (axis == GOMP_DIM_WORKER)
> > +{
> > + /* libgomp's nvptx plugin might potentially modify
> > +dims[GOMP_DIM_WORKER]. *
On 2016.01.19 at 15:23 +0100, Richard Biener wrote:
> On Tue, Jan 19, 2016 at 2:18 PM, Trevor Saunders
> wrote:
> > On Tue, Jan 19, 2016 at 01:11:44PM +0100, Jan Hubicka wrote:
> >> Hi,
> >> according to Trevor, the assumption about THIS pointer being non-NULL
> >> breaks
> >
> > That was Markus
On Tue, Jan 19, 2016 at 03:19:17PM +0100, Richard Biener wrote:
>
> It also seems we're wrongly using values defined for the host while
> looking at GIMPLE IL for the target.
>
> Bootstrap / regtest running on x86_64-unknown-linux-gnu.
>
> Ok?
>
> Richard.
>
> 2016-01-19 Richard Biener
>
>
Does this look ok?
> On Jan 15, 2016, at 5:41 PM, Ryan Burn wrote:
>
> This patch changes the function cilk_gimplify_call_params_in_spawned_fn to
> use gimplify_arg instead of gimplify_expr. It fixes an ICE when calling a
> function with a constructed empty class as the argument.
>
> Bootstra
On Tue, Jan 19, 2016 at 11:45 AM, Martin Jambor wrote:
> Hi,
>
> On Wed, Jan 13, 2016 at 06:39:25PM +0100, Martin Jambor wrote:
>> Hi,
>>
>> this is hopefully the last big re-post of the HSA patches...
>
> I have committed the combined patch as revision 232549 after
> bootstrapping and testing all
On Tue, Jan 19, 2016 at 2:18 PM, Trevor Saunders wrote:
> On Tue, Jan 19, 2016 at 01:11:44PM +0100, Jan Hubicka wrote:
>> Hi,
>> according to Trevor, the assumption about THIS pointer being non-NULL breaks
>
> That was Markus, not me.
>
>> several bigger C++ packages (definitly including Firefox,
On Fri, Jan 15, 2016 at 3:05 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> In this PR the ARMv8 vcvt instructions end up being conditionalised when
> they don't have a conditional form.
> setting the predicable attribute to "no" is not enough. We need to set the
> "conds" attribute to unconditional as w
On Tue, 19 Jan 2016, Kirill Yukhin wrote:
> Hello Richard,
> On 15 Jan 12:54, Richard Biener wrote:
> > On Fri, 15 Jan 2016, Kirill Yukhin wrote:
> >
> > > Hello,
> > > Thet patch in the bottom adds check if rhs is "useless_type_conversion_p"
> > > in vectorizable_store () to avoid subsequent gcc
OK, thanks.
Jason
It also seems we're wrongly using values defined for the host while
looking at GIMPLE IL for the target.
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Ok?
Richard.
2016-01-19 Richard Biener
* hsa-gen.c (get_memory_order_name): Use MEMMODEL_ constants
and name.
Hello Richard,
On 15 Jan 12:54, Richard Biener wrote:
> On Fri, 15 Jan 2016, Kirill Yukhin wrote:
>
> > Hello,
> > Thet patch in the bottom adds check if rhs is "useless_type_conversion_p"
> > in vectorizable_store () to avoid subsequent gcc_assert.
> >
> > This change is very similar to [1].
> >
On Mon, Jan 18, 2016 at 11:17:04AM -0500, Jason Merrill wrote:
> But we do currently print
>
> wa.C:1:24: warning: unused parameter ‘xs#0’ [-Wunused-parameter]
> wa.C:1:24: warning: unused parameter ‘xs#1’ [-Wunused-parameter]
> wa.C:1:24: warning: unused parameter ‘xs#2’ [-Wunused-parameter]
>
>
On Tue, 19 Jan 2016, Alexander Monakov wrote:
> > ... to determine an optimal number of threads per block given the number
> > of registers (maybe just querying CU_FUNC_ATTRIBUTE_MAX_THREADS_PER_BLOCK
> > would do that already?).
>
> I have implemented that for OpenMP offloading, but also since CU
Hi Catherine, Hi Eric, Hi Matthew,
GCC PR 69129 reports a problem with the MIPS backend:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69129
I traced the problem down to a race condition in
mips_compute_frame_info. This calls mips_global_pointer, which
through a torturous chain of inferi
OK, thanks.
Jason
On 01/19/16 06:49, Thomas Schwinge wrote:
(One problem certainly might be that we're currently not doing any
register allocation for nvptx, as far as I remember based on the idea
that PTX is only a "virtual ISA", and the PTX JIT compiler would "fix
this up" for us -- which I'm not sure it actual
On Tue, 19 Jan 2016, Thomas Schwinge wrote:
> Hi!
>
> With nvptx offloading, in one OpenACC test case, we're running into the
> following fatal error (GOMP_DEBUG=1 output):
>
> [...]
> info: Function properties for 'LBM_performStreamCollide$_omp_fn$0':
> info: used 87 registe
On 19 January 2016 at 14:22, Alan Lawrence wrote:
> On 19/01/16 09:46, Christophe Lyon wrote:
>>
>> On 19 January 2016 at 04:05, H.J. Lu wrote:
>>>
>>> On Thu, Dec 24, 2015 at 3:55 AM, Alan Lawrence
>>> wrote:
This version changes the test cases to fix failures on some platforms,
On Tue, Jan 19, 2016 at 10:00:00AM +0100, Richard Biener wrote:
> On Tue, 19 Jan 2016, Jakub Jelinek wrote:
> > Here is an attempt to fix ICE on statement expression in "m" asm input
> > operand. The problem is that gimplify_asm_expr attempts to mark it
> > addressable, but that can be just too la
On Tue, Jan 19, 2016 at 10:36:28 +0100, Jakub Jelinek wrote:
> On Tue, Jan 19, 2016 at 09:57:01AM +0100, Richard Biener wrote:
> > On Mon, 18 Jan 2016, Ilya Verbin wrote:
> > > On Fri, Jan 15, 2016 at 09:15:01 +0100, Richard Biener wrote:
> > > > On Fri, 15 Jan 2016, Ilya Verbin wrote:
> > > > > II
On 19/01/16 09:46, Christophe Lyon wrote:
On 19 January 2016 at 04:05, H.J. Lu wrote:
On Thu, Dec 24, 2015 at 3:55 AM, Alan Lawrence wrote:
This version changes the test cases to fix failures on some platforms, by
rewriting the initializers so that they aren't pushed out to the constant pool.
On Tue, Jan 19, 2016 at 01:11:44PM +0100, Jan Hubicka wrote:
> Hi,
> according to Trevor, the assumption about THIS pointer being non-NULL breaks
That was Markus, not me.
> several bigger C++ packages (definitly including Firefox, but I believe
> kdevelop was mentioned, too). This patch makes th
On 01/19/2016 02:08 PM, Jakub Jelinek wrote:
On Tue, Jan 19, 2016 at 01:27:32PM +0100, Bernd Schmidt wrote:
Is there a way to merge these two blocks (e.g. by moving this to the start
of the loop and testing for insn or BB_HEAD)?
Sure, like this?
That's ok. I'm assuming you know best how to u
On Tue, Jan 19, 2016 at 01:27:32PM +0100, Bernd Schmidt wrote:
> Is there a way to merge these two blocks (e.g. by moving this to the start
> of the loop and testing for insn or BB_HEAD)?
Sure, like this?
2016-01-19 Jakub Jelinek
PR debug/65779
* shrink-wrap.c: Include valtrac
On Tue, 19 Jan 2016, Jan Hubicka wrote:
> > On Tue, 19 Jan 2016, Jan Hubicka wrote:
> >
> > > Hi,
> > > here is updated patch. It has same effect as the former version.
> > >
> > > Bootstrapped/regtested x86_64-linux, OK?
> >
> > But what about the comment?
> >
> > We track no
> >
On Tue, Jan 19, 2016 at 01:42:00PM +0100, Jan Hubicka wrote:
> > One solution I do envision, which might help, would be to try to figure
> > out which types are unused, and discard those. Say, scan all variables
> > within a lexical scope (including nested blocks), deciding which ones
> > can be d
Hi!
The fix for this PR landed upstream, so I've cherry picked it, and after
bootstrapping/regtesting it on x86_64-linux last night committed to trunk.
2016-01-19 Jakub Jelinek
PR sanitizer/68824
* tsan/tsan_interceptors.cc (NEED_TLS_GET_ADDR, __tls_get_addr,
Initializ
> > On Tue, 19 Jan 2016, Jan Hubicka wrote:
> >
> > > Hi,
> > > here is updated patch. It has same effect as the former version.
> > >
> > > Bootstrapped/regtested x86_64-linux, OK?
> >
> > But what about the comment?
> >
> > We track no
> > information on whether given type i
> On Tue, 19 Jan 2016, Jan Hubicka wrote:
>
> > Hi,
> > here is updated patch. It has same effect as the former version.
> >
> > Bootstrapped/regtested x86_64-linux, OK?
>
> But what about the comment?
>
> We track no
> information on whether given type is used or not, so we h
Hi Christophe,
On 04/01/16 14:21, Christophe Lyon wrote:
On 4 January 2016 at 15:20, Christophe Lyon wrote:
On 18 December 2015 at 15:16, Kyrill Tkachov
wrote:
Hi Christophe,
On 17/12/15 22:17, Christophe Lyon wrote:
Hi,
Here is an updated version of this patch.
I did test it with
-mthum
On 01/19/2016 12:33 AM, Jakub Jelinek wrote:
+ if (MAY_HAVE_DEBUG_INSNS)
+{
+ for (dinsn = BB_END (bb); dinsn != insn; dinsn = PREV_INSN (dinsn))
+ if (DEBUG_INSN_P (dinsn))
+ {
+ df_ref use;
+ FOR_EACH_INSN_USE (use, dinsn)
+ if (refers_to_
On Tue, 19 Jan 2016, Jan Hubicka wrote:
> Hi,
> here is updated patch. It has same effect as the former version.
>
> Bootstrapped/regtested x86_64-linux, OK?
But what about the comment?
We track no
information on whether given type is used or not, so we have
to keep t
On 2016.01.19 at 13:11 +0100, Jan Hubicka wrote:
> according to Trevor, the assumption about THIS pointer being non-NULL breaks
> several bigger C++ packages (definitly including Firefox, but I believe
> kdevelop was mentioned, too). This patch makes the feature to be controlable
> by a dedicated
On 01/18/2016 11:44 PM, Jesper Broge Jørgensen wrote:
I found a formatting tool called uncrustify that comes with a gnu style
config
https://github.com/bengardner/uncrustify/blob/master/etc/gnu-indent.cfg
that needed a few tweaks to format code that looked what is already in
gcc/genattrtab.c
The
Hi,
this patch makes the code turning instrumentation thunks into transparent
aliases to work.
Bootstrapped/regtested x86_64-linux, will commit it later today.
Honza
* cgraphunit.c (cgraph_node::reset): Clear thunk info and
instrumented_version, too.
Index: cgraphunit.c
=
> So shall I take out the CONST_WIDE_INT/CONST_DOUBLE handling and just
> check for CONST_INT_P instead of CONST_SCALAR_INT_P ? I thought it is just
> easy thing to handle, though for DSE which cares about addresses it really
> does not matter. Or can I leave it in?
Your call.
> DSE will only c
1 - 100 of 129 matches
Mail list logo
