On 11/16/2015 12:54 PM, Eric Botcazou wrote:
Bootstrapped and tested on x86_64-linux. Ok?
OK once the 2/2 patch is also approved.
Thank you. The 2/2 has a small regrename piece to add target_data
fields, are you OK with that as well? I'm assuming Uros will take a look
at the rest.
Bernd
On 11/15/2015 11:55 AM, Tom de Vries wrote:
[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]
This patch series removes first_pass_instance.
1Remove first_pass_instance from pass_vrp
2Remove first_pass_instance from pass_reassoc
3Remove first_pass_insta
On 11/15/2015 11:14 PM, Dhole wrote:
gcc/c-family/ChangeLog:
2015-10-10 Eduard Sanou
I can't find a previous change from you in the sources, so the first
question would be whether you've gone through the copyright assignment
process.
Bernd
On 11/13/2015 11:30 PM, Marc Glisse wrote:
+__asm__("posix_memalign");
Can't say I like the __asm__ after the #if/#else/#endif block.
It might also cause trouble if some systems like to prepend an
underscore, maybe?
Yeah, that's one of the things I had in mind when I suggested moving
this
So Jeff and I just had a chat, and we came up with some thoughts about
how to proceed. I think we both agree that it would be good to have a
special testing backend, along with frontends designed to be able to
read in gimple or rtl that can be operated on. That's more of a
long-term thing.
Fo
On 11/16/2015 03:07 PM, Kyrill Tkachov wrote:
I've explained in the comments in the patch what's going on but the
short version is trying to change the destination of a defining insn
that feeds into an extend insn is not valid if the defining insn
doesn't feed directly into the extend insn. In t
For some of the simpler infrastructure tests such as the ones in this
patch kit (bitmap, vec or wide-int functionality testing and such), we
had the idea of putting these into every ENABLE_CHECKING compiler, and
run them after building stage1, controlled by a -fself-test flag. It's
better to det
On 11/16/2015 09:50 PM, David Malcolm wrote:
The root cause is uninitialized data. Specifically, the C parser's
struct c_expr gained a "src_range" field, and it turns out there are a
few places where I wasn't initializing this when returning c_expr
instances on the stack, and in some cases the v
On 11/17/2015 10:08 AM, Kyrill Tkachov wrote:
Yes, I had considered that as well. It should be equivalent. I didn't
use !reg_used_between_p because I thought
it'd be more expensive than checking reg_overlap_mentioned_p since we
must iterate over a number of instructions
and call reg_overlap_menti
On 11/17/2015 12:49 PM, Ilya Enkovich wrote:
Default hook for get_mask_mode is supposed to return integer vector
modes. This means it should reject calar modes returned by
mode_for_vector. Bootstrapped and regtested on
x86_64-unknown-linux-gnu, regtested on aarch64-unknown-linux-gnu. OK
for tr
On 11/16/2015 04:48 PM, Andre Vieira wrote:
On 16/11/15 15:34, Joern Wolfgang Rennecke wrote:
I just happened to stumble on this problem with another port.
The volatile & test solution doesn't work, though.
What does work, however, is:
__asm__ ("" : : "" (dummy));
I can confirm that Joern's
On 11/17/2015 02:53 AM, Mike Stump wrote:
On Nov 16, 2015, at 3:12 PM, Jeff Law wrote:
So I'd tend to want them either at the end of the file with a
single #if CHECKING_P or as a separate foo-tests file.
Hum… I kinda don’t want the main files mucked up with tests. I
think I’d rather have
#
On 11/17/2015 04:13 PM, David Malcolm wrote:
On Mon, 2015-11-16 at 22:34 +0100, Bernd Schmidt wrote:
Should c_expr perhaps acquire a constructor so that this problem is
avoided in the future? The whole thing seems somewhat error-prone.
I agree that it's error prone, and the ctor approa
On 11/13/2015 05:02 PM, Wilco Dijkstra wrote:
* gcc/ccmp.c (expand_ccmp_expr): Extract cmp_code from return value
of
expand_ccmp_expr_1.
I was trying to review this part of the patch in isolation and got very
confused because the patch also changes the return values of the ccmp
On 11/17/2015 02:03 PM, Kyrill Tkachov wrote:
+ || !reg_overlap_mentioned_p (tmp_reg, SET_SRC (PATTERN (cand->insn
return false;
Well, I think the statement we want to make is
"return false from this function if the two expressions contain the same
register number".
I loo
On 11/16/2015 07:18 PM, Uros Bizjak wrote:
On Fri, Nov 13, 2015 at 9:47 PM, Bernd Schmidt wrote:
This adds a new -mmitigate-rop option to the i386 port. The idea is to
mitigate against certain forms of attack called "return oriented
programming" that some of our security folks are
On 11/10/2015 11:19 AM, Bin.Cheng wrote:
On Tue, Nov 10, 2015 at 6:06 PM, Bernd Schmidt wrote:
Multi-line expressions should be wrapped in parentheses so that emacs/indent
can format them automatically. Two sets of parens are needed for this.
Operators should then line up appropriately.
Ah
On 11/18/2015 05:16 PM, Marek Polacek wrote:
Actually, no, I think we should do this instead.
+++ gcc/c-family/c-common.c
@@ -1924,7 +1924,7 @@ warn_tautological_cmp (location_t loc, enum tree_code
code, tree lhs, tree rhs)
/* We do not warn for constants because they are typical of macro
On 11/17/2015 07:35 PM, Wilco Dijkstra wrote:
I've updated the comments and documentation, see below. I hope it makes
sense now - returning rtx that computes the same value as the tree
expression
we're emitting is the most useful thing one can do.
The target-independent part is ok. Note that s
Ok, so this is a thorny problem. I thought I had a solution, and I'll
start by describing it, but in the end I think it doesn't actually work.
On 11/06/2015 10:09 PM, Jeff Law wrote:
On 11/06/2015 12:30 PM, Bernd Schmidt wrote:
Well, I think if MEM_READONLY_P is insufficient (a
On 11/18/2015 11:44 PM, Jakub Jelinek wrote:
noce_try_abs optimizes these cases normal abs, which doesn't really
care if the original condition is x < 0 ? -x : x or x <= 0 ? -x : x,
but also the x < 0 ? ~x : x case. But in this case it is significant
whether for x == 0 ~x or x applies; the follo
On 11/19/2015 12:18 AM, Jakub Jelinek wrote:
As the testcase shows, shrink-wrapping is incompatible with
ix86_static_chain_on_stack, where we rely on the very first instruction
in the (nested) function to be pushl %esi and use alternate entry
point right after that pushl instruction (one byte aft
On 11/18/2015 05:32 PM, Richard Sandiford wrote:
Do the usual dance when assigning to SUBREG_PROMOTED_VAR_P destinations:
first convert to the outer mode, then extend to the inner mode.
This fixes the powerpc64le bootstrap failure reported in PR 68393.
Ok.
Bernd
On 11/19/2015 12:02 AM, Jakub Jelinek wrote:
2015-11-18 Jakub Jelinek
PR preprocessor/60736
* include/cpplib.h (cpp_errno_filename): New prototype.
* errors.c (cpp_errno): Don't handle msgid "" specially, use
_(msgid) instead of msgid as argument to cpp_error.
(This is on the RL78 target where HImode values occupy two hard
registers and QImode values only one. The bug however is generic, not
RL78 specific).
The REE pass transforms this into:
(insn 44 (set (reg:QI r11) (mem:QI (reg:HI r20)))
(insn 45 (set (reg:HI r10) (zero_ext
On 11/19/2015 01:50 AM, Joseph Myers wrote:
I don't think all the reformattings here are things we want to do globally
for most source files.
While I do appreciate the sentiment behind the patch, I agree with all
of Joseph's points. Especially the clearly incorrect changes should be
reverted
On 11/19/2015 01:02 PM, Eric Botcazou wrote:
this fixes the glitch I introduced when trying to fix another bug:
https://gcc.gnu.org/ml/gcc-patches/2012-05/msg00330.html
The --with-plugin-ld value specified by the user is also stripped, although
that's unnecessay to fix the original bug. So I
On 11/19/2015 11:16 AM, Martin Liška wrote:
You are right, however as the original coding style was really broken,
it was much easier
to use the tool and clean-up fall-out.
Waiting for thoughts related to v2.
Better, but still some oddities. I hope you won't get mad at me if I
suggest doing t
On 11/19/2015 03:28 PM, Ilya Enkovich wrote:
This is a refactoring patch discussed in another thread [1]. It gets
rid of CODE_FOR_nothing usage in optabs-tree.c by introducing boolean
predicated in optabs-query. Bootstrapped and regtesed on
x86_64-unknown-linux-gnu.
Looks pretty reasonable, b
On 11/19/2015 04:34 PM, Nick Clifton wrote:
Hi Bernd,
I had a look around. There's code testing HARD_REGNO_NREGS in
ree.c:combine_set_extension. It's inside #if 0, and labelled
"temporarily disabled". See if enabling that helps you? (Jeff, that #if
0 was added by you).
I suspect that the code
On 11/19/2015 05:13 PM, Michael Matz wrote:
in an enabled-checking compiler gcc_checking_assert is always executed.
If that depends on things having happened under flag_checking being true,
but it's actually false during runtime due to -fno-checking things go
awry, like segfaulting in this case.
On 11/19/2015 05:31 PM, Ilya Enkovich wrote:
Currently we fold all memcpy/memmove calls with a known data size.
It causes two problems when used with Pointer Bounds Checker.
The first problem is that we may copy pointers as integer data
and thus loose bounds. The second problem is that if we inl
g things, and IMO we should just restrict
the candidates for optimization much earlier.
Also, I want to apply the following. Ok if testing succeeds?
Bernd
commit ce68938b5150f5d41a54ed317ab97d98461be064
Author: Bernd Schmidt
Date: Thu Nov 19 17:38:15 2015 +0100
Readabi
In general I'm much happier with this approach, and I think this series
is close to ready, but I want to bring up some questions that could use
wider discussion.
This patch adds a selftest.h/.c to gcc, with an API loosely
modelled on gtest (though without the use of CamelCase): it
supports eno
On 11/19/2015 07:08 PM, David Malcolm wrote:
gcc_assert terminates the process and no further testing is done,
whereas the approach the kit tries to run as much of the testsuite as
possible, and then fail if any errors occurred.
Yeah, but let's say someone is working on bitmaps and one of the b
I1 is def_insn, I3 is cand->insn. tmp_reg is 'ax'. What we want to do
is reject this transformation
because the destination of def_insn (aka I1), that is 'ax', is not the
operand of the extend operation
in cand->insn (aka I3). As you said, rtx_equal won't work on just
SET_SRC (PATTERN (cand->insn)
BTW, I'm with whoever said absolutely no way to the idea of making
automatic changes like this as part of a commit hook.
I think the whitespace change can go in if it hasn't already, but I
think the other one still has enough problems that I'll say - leave it
for the next stage 1.
@@ -178,8
On 11/19/2015 12:49 AM, Jeff Law wrote:
On 11/18/2015 12:16 PM, Bernd Schmidt wrote:
I don't think so, actually. One safe option would be to rip it out and
just stop transforming this case, but let's start by looking at the code
just a bit further down, calling noce_can_store_specu
On 11/23/2015 02:49 PM, marxin wrote:
Following series has been just bootregtested on x86_64-linux-gnu
(all patches together).
All ok except 5/6 which I'm not finding obvious. Better to have a
cilk/c++ person have a look.
In the future, a few more explanations would help with reviewing. Let'
On 11/22/2015 09:58 PM, Uros Bizjak wrote:
On Sun, Nov 22, 2015 at 11:38 AM, Richard Henderson wrote:
* optabs.def (uaddv4_optab, usubv4_optab): New.
* internal-fn.c (expand_addsub_overflow): Use them.
* doc/md.texi (Standard Names): Add uaddv4, usubv4.
* config/i386/i386.c (ix86_cc_mode): Ext
On 11/23/2015 06:52 PM, David Malcolm wrote:
This patch fixes PR c/68473 by bulletproofing the new
diagnostic_show_locus implementation against ranges that finish before
they start (which can happen when using the C preprocessor), falling
back to simply printing a caret.
Hmm, wouldn't it be bet
As I mentioned in a prior message on the subject, this is only a problem
when the source/dest of the extension are the same. When the
source/dest of the extension are different, we only optimize when the
original set and extension are in the same block and we verify that all
affected registers ar
On 11/24/2015 12:09 AM, Mikhail Maltsev wrote:
The attached patch fixes a problem introduced in r229567: the assertion
gcc_assert (is_sse);
is checked if flag_checking is false, and this causes an ICE when compiling with
-fno-checking.
Ok.
Bernd
On 11/23/2015 07:26 PM, David Malcolm wrote:
In theory we could attempt to try to handle this kind of thing by
looking at the macro expansions, and to print something like:
13 TEST_EQ (fmin);
^~~~
6 if ((long)FUNC##l(xl,xl) != (long)xl) \
On 11/23/2015 05:52 PM, Ilya Verbin wrote:
There are 2 new uses of "#ifdef ENABLE_OFFLOADING" in c_parser_oacc_declare and
cp_parser_oacc_declare.
I don't know how to properly test OpenACC, so here is untested patch.
It's documented on the Offloading wiki page, but this patch is good
enough i
On 11/24/2015 02:15 PM, Kyrill Tkachov wrote:
This bug also affects GCC 5 and 4.9. I've confirmed that this patch
fixes the miscompilations on those branches.
Bootstrap and test on x86_64 on the GCC 5 branch is successful. Same on
4.9 is ongoing.
The patch applies cleanly to all branches.
So ok t
On 11/24/2015 07:13 PM, Segher Boessenkool wrote:
PR rtl-optimization/68520
* shrink-wrap.c (try_shrink_wrapping): Don't push a block to VEC if
its bit was already set in BB_WITH.
Ok.
Bernd
a test cycle.
Bernd
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 49fa59b..1e788e8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,11 @@
+2015-11-25 Bernd Schmidt
+
+ * ifcvt.c (noce_mem_write_may_trap_or_fault_p,
+ noce_can_store_speculate): Delete.
+ (noce_process_if_block
On 11/23/2015 05:05 PM, Michael Matz wrote:
It only does so under some conditions, amongst them if it sees a
dominating access to the same memory of the same type (load or store) and
size. So it doesn't introduce writes on paths that don't already contain
a write, and hence are multi-thread saf
On 11/25/2015 03:26 AM, David Malcolm wrote:
Consider the case where an assumption that the host is little-endian
assumption creeps into one of the bitmap functions. Some time later,
another developer updates their working copy from svn on a big-endian
host and finds that lots of things are brok
On 11/24/2015 09:03 PM, Jeff Law wrote:
Although this looks weird, it's deliberate, and follows the pattern
earlier in those test files: the diagnostics are injected by the plugin,
not by cc1. The plugin gives us a way of unit-testing how
diagnostic_show_locus handles the various ways of callin
On 11/24/2015 04:12 PM, Kyrill Tkachov wrote:
arg->value to the stack frame at argblock.
arg->value is:
(mem/c:BLK (plus:SI (reg/f:SI 104 virtual-incoming-args)
(const_int 20 [0x14])) [1 from+0 S20 A32])
and argblock is:
(plus:SI (reg/f:SI 104 virtual-incoming-args)
(const_int 16 [
On 11/25/2015 01:41 PM, Bernd Schmidt wrote:
/* arg.locate doesn't contain the pretend_args_size offset, it's part of
argblock. Ensure we don't count it in I. */
#ifdef STACK_GROWS_DOWNWARD
i -= crtl->args.pretend_args_size
#else etc.
Hmm, yours looks equivalent, j
On 11/25/2015 01:56 PM, Dominik Vogt wrote:
The attached patch fixes a warning during Linux kernel compilation
on S/390 due to -mwarn-dynamicstack and runtime alignment of stack
variables with constant size causing cfun->calls_alloca to be set
(even if alloca is not used at all). The patched cod
On 11/25/2015 01:21 PM, Richard Sandiford wrote:
- (plus:SI (match_operand:SI 0 "s_register_operand" "l, r")
- (match_operand:SI 1 "arm_add_operand""lPv,rIL"))
+ (plus:SI (match_operand:SI 0 "s_register_operand" "l,l, r,r")
+ (match_operand:S
On 11/25/2015 03:10 PM, Kyrill Tkachov wrote:
What should we do when we don't have STACK_GROWS_DOWNWARD? Do we need to
write:
if (STACK_GROWS_DOWNWARD)
i -= crtl->args.pretend_args_size;
else
i += crtl->args.pretend_args_size;
I think so. I mean, this should mirror this code here, right?
On 11/25/2015 03:52 PM, Dominik Vogt wrote:
Without looking into the details, I believe it's an optimization
to have certain frequently used members of the struct always on
the same cache line.
Probably better to annotate the global vars then with an alignment,
rather than waste space on the s
On 11/25/2015 03:54 PM, Kyrill Tkachov wrote:
And here it is.
This fixes the bug on arm and tests on arm look ok.
I've kicked off bootstraps and tests on arm, aarch64 and x86_64.
Ok for trunk if they come back clean?
Sure. Thanks! (Backport too.)
Bernd
On 11/25/2015 04:00 PM, Jakub Jelinek wrote:
nonfreeing_call_p is one necessary condition (if that is true, it means
the call could mean that the first access does not trap while the second one
does).
But I agree that we need a predicate for nonbarrier_call_p or similar.
Some atomic builtins are
On 11/25/2015 01:35 PM, Richard Sandiford wrote:
The define_subst support made it syntactically possible to add
attributes to a define_expand, but until now they had been ignored
by genattrtab.c. This patch allows define_expands to have
"code,alternative" attributes but raises an error for gener
On 11/25/2015 01:26 PM, Richard Sandiford wrote:
Later patches in the series add a new form of attribute that takes the
attribute number as an argument, rather than it being stored in the
global which_alternative variable.
Having both a local alternative number and a global alternative number
is
I'm reading up on this stuff, but I'm probably still not the best person
to review the actual frequency manipulation parts in this. There are a
few things I can comment on, however.
The first question would be, have you looked at the rebuild_frequencies
code in predict.c, and whether you can r
On 11/25/2015 05:19 PM, Richard Sandiford wrote:
I guess not, but without it we have both local and global variables
called which_alternative.
So call the local ones something else (alt_to_check, requested_alt or
attr_alt)?
Bernd
On 11/25/2015 11:47 PM, David Malcolm wrote:
FWIW, the reason I special-cased the linked list was to avoid any
dynamic memory allocation: the ctors run before main, so I wanted to
keep them as simple as possible.
Is there any particular reason for this? C++ doesn't disallow memory
allocation i
On 11/26/2015 12:12 PM, Kyrill Tkachov wrote:
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index af7a3b9..3e3dc8d 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -2220,7 +2220,7 @@ noce_try_cmove_arith (struct noce_if_info *if_info)
}
}
-if (emit_a && modified_in_a)
+if (emit_a |
On 11/25/2015 01:20 PM, Richard Sandiford wrote:
This series fixes PR 68432, a regression caused by my internal-functions-
for-optabs series. Some of the libm optabs in i386.md have a true HAVE_*
condition but conditionally FAIL if we're optimising for size:
if (SSE_FLOAT_MODE_P (mode) && TA
On 11/26/2015 02:52 PM, Kyrill Tkachov wrote:
On 26/11/15 13:40, Bernd Schmidt wrote:
On 11/26/2015 12:12 PM, Kyrill Tkachov wrote:
modified_in_b = emit_b != NULL_RTX && modified_in_p (orig_a,
emit_b);
Can this ever be true? We arrange for emit_b to set a new pseudo,
don'
On 11/25/2015 05:08 PM, Richard Sandiford wrote:
Also, using a string like that rather than some kind of
identifier or a define_icode_attr maybe isn't the best approach?
By "some kind of identifier" do you just mean replacing "code,alternative"
with a string that doesn't have a comma?
Yeah. I
On 11/26/2015 03:35 PM, Kyrill Tkachov wrote:
Would it be ok if I did that as a separate follow-up patch?
We don't have a testcase where this actually causes trouble and I'd like
to keep the fix for
this PR as self-contained as possible.
Sure.
Bernd
On 11/26/2015 04:13 PM, Richard Sandiford wrote:
That would mean that the validity of a gimple call would depend on both
the target predicates and whether the block containing the statement
is optimised for size or speed. So whenever we want to test whether
a gimple call is valid, we'd need to
On 11/26/2015 05:22 PM, Richard Sandiford wrote:
It also isn't suitable for optabs because the conditions are cached
by init_optabs. I suppose we could have a separate cache for size
and speed though.
That sounds necessary given the existence of such insn conditions,
unless we want to disallo
On 11/26/2015 05:45 PM, Kyrill Tkachov wrote:
that doesn't help, punt. */
- modified_in_a = emit_a != NULL_RTX && modified_in_p (orig_b, emit_a);
if (tmp_b && then_bb)
{
These bits I thought would be part of a followup patch (which would also
guard against single_set proble
On 11/26/2015 09:53 PM, Martin Liška wrote:
Is the patch still candidate to be merged in current stage3, or should I
leave it to the next stage1?
What about the first patch or the patch, where I just applied
replacement of whitespaces?
As I said previously, the one to just replace whitespace is
On 11/26/2015 01:16 PM, Jonathan Wakely wrote:
At https://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html we document
-Waggressive-loop-optimizations but you can't find that option at
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html because we
document -Wno-aggressive-loop-optimizations in
This is a patch for PRs 68471 and 68472, which show problems with the
ROP mitigation:
* reg-stack doesn't call df_insn_update when it makes changes, and
if df checking is enabled, any subsequent df_analyze call will
abort
* Using -mcmodel=medium fails because of a pattern that has lea typ
On 11/26/2015 09:59 PM, Martin Liška wrote:
I'm sending v2 of the patch, where I removed adding of 'const' to
certain function arguments.
Apart from that, I found one more leak related to cilk. As I've retested
in valgrind, there
should not be any memory leak related to cilk.
Ready to be install
On 11/27/2015 10:26 AM, Eric Botcazou wrote:
+#ifdef STACK_REGS
+ if (regstack_completed
+ && REG_P (recog_data.operand[i])
+ && IN_RANGE (REGNO (recog_data.operand[i]),
+ FIRST_STACK_REG, LAST_STACK_REG))
+ u
On 11/27/2015 10:45 AM, Kyrill Tkachov wrote:
As discussed, I've added a check for multiple_sets to
insn_valid_noce_process_p and replaced the
modified_a and modified_b redundant definitions with
checking asserts to catch cases if any unexpected multiple
sets get through the net.
Ok, thanks!
On 11/26/2015 10:46 AM, Richard Biener wrote:
Ok with the change suggested by Micha for the asm()s. Note that I
originally used gimple_vuse () instead of gimple_vdef () as even
reading random memory is a barrier for the compiler to move stores
across it (not reads, of course). Which is why I a
On 11/27/2015 01:30 PM, Jiří Engelthaler wrote:
Sorry for international characters in my name. It should be
Jiri Engelthaler
2015-11-27 13:29 GMT+01:00 Engelthaler Jiří :
There is precedent for non-ASCII characters in ChangeLogs. Grep for
Rafael Ávila de Espíndola. But I think there should b
On 11/27/2015 03:33 PM, Kyrill Tkachov wrote:
Sorry for that.
That is caused not by this patch but rather by the followup
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03327.html
The checking assert fails:
gcc_checking_assert (!emit_a || !modified_in_p (orig_b, emit_a));
emit_a is:
(parallel [
On 11/29/2015 08:32 PM, Andreas Tobler wrote:
Hi all,
the attached patch prepares the testsuite, c and c++, for the upcoming
ASAN support for FreeBSD (x86_64 first).
I tested the patch on CentOS7.1 x86_64 and on FreeBSD x86_64.
Results can be seen on the list.
Is this ok for trunk?
-/* { dg-d
On 11/29/2015 06:14 PM, H.J. Lu wrote:
Is this safe for stage 3?
Is there a reason to do it now? This doesn't include a testcase.
* function.c (assign_parm_setup_stack): Force source into a
register if needed.
* target.def (function_incoming_arg): Update documentation
On 11/30/2015 01:00 AM, Matthias Klose wrote:
link libgccjit using LDFLAGS (which is empty by default), but could be
used to pass hardening options like -Wlz,relro.
Ok when stage 1 opens.
Bernd
On 11/30/2015 01:12 PM, Andreas Tobler wrote:
On 30.11.15 11:28, Bernd Schmidt wrote:
On 11/29/2015 08:32 PM, Andreas Tobler wrote:
-/* { dg-do run { target { *-*-linux* } } } */
+/* { dg-do run { target { *-*-linux* *-*-freebsd* } } } */
I see a patch from you to add asan support to x86
On 11/27/2015 10:02 AM, Bernd Schmidt wrote:
This is a patch for PRs 68471 and 68472, which show problems with the
ROP mitigation:
* reg-stack doesn't call df_insn_update when it makes changes, and
if df checking is enabled, any subsequent df_analyze call will
abort
* Using -mc
On 12/01/2015 06:31 AM, Gary Funck wrote:
At this time, we would like to re-submit the UPC patches for comment
with the goal of introducing these changes into GCC 6.0.
This has missed stage 1 by a few weeks, we'd have to make an exception
to include it at this late stage.
@@ -857,9 +875,14
On 11/26/2015 05:22 PM, Richard Sandiford wrote:
Bernd Schmidt writes:
I wish we'd taken some more time to think through the consequences of
the original internal_fn patchset.
I don't think this PR shows that the approach was wrong.
I think it does. Internal functions
On 12/01/2015 01:16 PM, Richard Biener wrote:
On Tue, Dec 1, 2015 at 12:54 PM, Bernd Schmidt wrote:
On 11/26/2015 05:22 PM, Richard Sandiford wrote:
Bernd Schmidt writes:
I wish we'd taken some more time to think through the consequences of
the original internal_fn patchset.
I
(add gcc-patches)
On 12/01/2015 08:39 AM, Matthias Klose wrote:
On 01.12.2015 03:58, Ulrich Drepper wrote:
On Mon, Nov 30, 2015 at 9:14 PM, Jeff Law wrote:
Right, but isn't AC_COMPILE_IFELSE a compile test, not a run test?
The problem macro is _AC_COMPILER_EXEEXT_WORKS. The message is at
On 12/01/2015 02:43 PM, Richard Sandiford wrote:
I don't think what you say is an argument that the approach is wrong.
The C conditions for optabs have always been more restricted than
other define_expands and define_insns, since they cannot refer
to operands. When caching of optabs was added, t
One problem I have whenever I try to edit i386.md is that I can't find
the patterns I'm looking for. Let's say I'm looking for lshrsi3, but
there's no pattern by this name, what I'm looking for is
"3". Even worse are things like "*xordi_2", which has
just "*_2" and can't reasonably be searched
On 12/01/2015 04:23 PM, Jakub Jelinek wrote:
On Tue, Dec 01, 2015 at 04:14:21PM +0100, Bernd Schmidt wrote:
One problem I have whenever I try to edit i386.md is that I can't find the
patterns I'm looking for. Let's say I'm looking for lshrsi3, but there's no
patte
On 12/01/2015 04:28 PM, Alexander Monakov wrote:
Bernd, is your position on exposing shared memory as first-class address space
on NVPTX subject to change? Do you remember what middle-end issues you've
encountered when trying that?
TYPE_ADDR_SPACE does not reliably contain the address space. P
On 12/01/2015 04:28 PM, Alexander Monakov wrote:
I'm taking a different approach. I want to execute all insns in all warp
members, while ensuring that effect (on global and local state) is that same
as if any single thread was executing that instruction. Most instructions
automatically satisfy
On 12/01/2015 04:31 PM, Bernd Schmidt wrote:
On 12/01/2015 04:23 PM, Jakub Jelinek wrote:
With the comments in the *.md file I'd worry about them getting out of
date,
or people feeling they have to edit them manually (rather than being
regenerated or whatever).
I suppose we could h
On 12/01/2015 10:15 PM, Richard Sandiford wrote:
[This is a less invasive fix for the PR, without any changes to
the .md attribute handling]
As a minimal fix I like this much better. I'll ok it under the condition
that you have verified in all ports that size/speed issues are the only
reaso
What exactly is the problem with having asm files? I'm asking because
this...
On 12/01/2015 04:28 PM, Alexander Monakov wrote:
+/* __shared__ char *__nvptx_stacks[32]; */
+asm ("// BEGIN GLOBAL VAR DEF: __nvptx_stacks");
+asm (".visible .shared .u64 __nvptx_stacks[32];");
+
+/* __shared__ unsi
On 12/01/2015 04:28 PM, Alexander Monakov wrote:
This allows to use COND_EXEC patterns on nvptx. The backend is mostly ready
for that, although I had to slightly fix nvptx_print_operand. I've also opted
to make calls predicable to make the uniform-simt patch simpler, and to that
end I need a sm
On 12/02/2015 02:46 PM, Jakub Jelinek wrote:
Or does the OpenACC execution model not allow anything like that, i.e.
have some function with an automatic variable pass the address of that
variable to some other function and that other function use #acc loop kind
that expects the caller to be at th
501 - 600 of 2198 matches
Mail list logo
