.
Aldy
commit 7d371b0f69b8ff74a6fd17773dd5fde80687a698
Author: Aldy Hernandez al...@redhat.com
Date: Fri Sep 26 08:24:38 2014 -0700
* dwarf2out.c (dwarf2out_early_global_decl): Do not set cfun.
(gen_variable_die): Set origin_die before we exit early.
diff --git a/gcc/dwarf2out.c b
the previously generated die.
Fixed. Cleaned some other trivia. Committed to branch.
No guality regressions for any languages. All target libraries built.
Aldy
commit 10d7286a26e8a0e29ecbbd0b362ecb8fcc8bfc62
Author: Aldy Hernandez al...@redhat.com
Date: Fri Sep 26 11:11:27 2014 -0700
drops into this codepath regardless, and has/had that
gcc_checking_assert anyhow.
No regressions.
Committed to branch.
Aldy
commit a23ae1821d5c45b2c56ea5db6940ea8982f8fd69
Author: Aldy Hernandez al...@redhat.com
Date: Mon Sep 29 11:48:41 2014 -0700
* dwarf2out.c (gen_subprogram_die
On 09/30/14 03:23, Richard Biener wrote:
On Mon, Sep 29, 2014 at 8:54 PM, Aldy Hernandez al...@redhat.com wrote:
I'm rearranging some code in Michael's original patch to minimize the
difference with mainline.
It seems that the check for DECL_STRUCT_FUNCTION (decl)-gimple_df, was
merely a check
can see if we have too many DIEs
that were NOT generated early. It is likely this will only be a
temporary hacking tool to check I didn't do anything stupid along :).
How does this look?
Aldy
commit d9b215d7c3aeea2c601e0d983cbe424990c1beab
Author: Aldy Hernandez al...@redhat.com
Date: Tue
On 10/01/14 07:04, Richard Biener wrote:
No, checking -gimple_df would be odd indeed. The check seems to be coming from
Michas patch-set?
Correct.
: Aldy Hernandez al...@redhat.com
Date: Wed Oct 1 14:26:06 2014 -0700
* cp/decl2.c (emit_debug_for_namespace): Emit early debug
information for all DECLs instead of just the statics.
Include debug.h.
* passes.c (rest_of_decl_compilation): Add reminder that we could
On 10/02/14 08:46, Jason Merrill wrote:
On 10/01/2014 05:31 PM, Aldy Hernandez wrote:
+ for (tree t = level-names; t; t = TREE_CHAIN(t))
+if (TREE_CODE (t) != TYPE_DECL
+ TREE_CODE (t) != PARM_DECL
+ !DECL_IS_BUILTIN (t))
+ debug_hooks-early_global_decl (t);
What does
On 10/02/14 08:53, Jason Merrill wrote:
On 09/30/2014 02:43 PM, Aldy Hernandez wrote:
+ if (parm_die
+ /* Make sure the function to which this parameter belongs to is
+ not an abstract instance. If it is, we can't reuse anything.
+ We must create a new DW_TAG_formal_parameter
On 10/02/14 12:56, Richard Biener wrote:
Yes, but I don't see why we need the cleanup step. The decls are real after all.
You won't hear me complain.
I was just worried people were going to start complaining about larger
.debug_info sections, since I see that the current code, as it stands
I know It just makes me feel better to know we're in agreement. Old habits
die hard I guess ;-).
On Oct 3, 2014 7:08 AM, Jason Merrill ja...@redhat.com wrote:
On 10/02/2014 03:24 PM, Aldy Hernandez wrote:
If you aOn 10/02/2014 03:24 PM, Aldy Hernandez wrote:
If you are ok
Is there a reason we don't create etags for toplevel include files? If
not, could I please apply this patch?
Thanks.
Aldy
commit a679529d14f005d8c88517f72d2b5295d8c82f0f
Author: Aldy Hernandez al...@redhat.com
Date: Tue Oct 7 09:32:21 2014 -0700
* Makefile.in (TAGS): Tag ../include
Errr... a static that only gets written to?
OK to commit?
commit 7b1c19385fd06d6a2d0844d453bf1c7683071440
Author: Aldy Hernandez al...@redhat.com
Date: Tue Oct 7 10:14:02 2014 -0700
* dwarf2out.c: Remove current_function_has_inlines.
(gen_subprogram_die): Same
PING
On 10/07/14 09:37, Aldy Hernandez wrote:
Is there a reason we don't create etags for toplevel include files? If
not, could I please apply this patch?
Thanks.
Aldy
On 10/13/14 09:27, Jeff Law wrote:
On 10/13/14 08:53, Aldy Hernandez wrote:
PING
On 10/07/14 09:37, Aldy Hernandez wrote:
Is there a reason we don't create etags for toplevel include files? If
not, could I please apply this patch?
ENOPATCH
jeff
Sorry, patch was in original message
is the one that takes
precedence within the innermost scope.
With this patch, we get one less DIE for this scenario on mainline,
while fixing other problems in early dwarf. Double yay!
Aldy
commit 81de7d658e94160426b38e6c43c09a484fb530ba
Author: Aldy Hernandez al...@redhat.com
Date: Fri Oct
appreciated. Basically I'm looking for feedback and
positive reinforcement that this is all eventually useful :).
Aldy
p.s. Committed to branch.
commit 850d7f8460c1be9865ba4c45c6c56c346b4199e0
Author: Aldy Hernandez al...@redhat.com
Date: Fri Oct 10 13:34:04 2014 -0700
* cp/decl2.c
On 10/28/14 07:40, Michael Matz wrote:
Hi,
On Mon, 27 Oct 2014, Aldy Hernandez wrote:
Here I use a new tree bit (BLOCK_DIE) to store the DIE-block
relationship. This will have to be adapted and streamed for LTO.
You might consider using an on-the-side tree-hash map. Saves memory when
This doesn't seem to be used anywhere but in dwarf2out.c.
OK for mainline?
commit 8a48cdd576442cee103399ab4f1f67ee215ee6b8
Author: Aldy Hernandez al...@redhat.com
Date: Tue Aug 26 14:30:22 2014 -0700
* dwarf2out.h (dwarf2out_decl): Remove prototype.
* dwarf2out.c
, but feel free to comment.
Committed to branch.
Aldy
commit 71d1672200b6bcfe258ae0bfe92ea59af3ea
Author: Aldy Hernandez al...@redhat.com
Date: Tue Aug 26 19:12:17 2014 -0700
* dwarf2out.c (struct die_struct): Add dumped_early field.
(reparent_child): New.
(splice_child_die
On 08/28/14 06:58, Richard Biener wrote:
On Wed, Aug 27, 2014 at 4:42 AM, Aldy Hernandez al...@redhat.com wrote:
This patch fixes a bunch of guality failures. With it I get 144 guality.exp
failures vs. 163 for make check-gcc RUNTESTFLAGS=guality.exp. A lot
better than 100% fail rate
:
On 08/28/2014 01:34 PM, Aldy Hernandez wrote:
I wonder if instead of early dumping of all the DECLs, we could only
dump the toplevel scoped DECLs, and let inheritance set the proper
contexts.
Yes, I think this makes a lot more sense; do it at a well-defined point
in compilation rather than
I think this merge caused bootstrap failure on Linux/i686
https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00010.html
I incorrectly pushed my branch onto trunk. It's being reverted.
On 09/04/14 11:23, Richard Biener wrote:
On September 4, 2014 7:54:14 PM CEST, Aldy Hernandez al...@redhat.com wrote:
I think this merge caused bootstrap failure on Linux/i686
https://gcc.gnu.org/ml/gcc-regression/2014-09/msg00010.html
I incorrectly pushed my branch onto trunk. It's
be2a57c0df761552944acacacf4c43b1e36f2f2c
Author: Aldy Hernandez al...@redhat.com
Date: Thu Sep 4 10:35:20 2014 -0700
* Makefile.in (TAGS): Handle constructs in timevar.def.
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 63124f8..df879b1 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
On 09/04/14 03:42, Richard Biener wrote:
On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez al...@redhat.com wrote:
Flow-wise I still want to move hand-off to the cgraph code to toplev.c,
out from the FEs final_write_gloabals hook:
/* This must also call finalize_compilation_unit
On 09/05/14 02:00, Richard Biener wrote:
[jason: C++ questions throughout.]
On Fri, Sep 5, 2014 at 4:38 AM, Aldy Hernandez al...@redhat.com wrote:
On 09/04/14 03:42, Richard Biener wrote:
On Wed, Sep 3, 2014 at 7:54 PM, Aldy Hernandez al...@redhat.com wrote:
I meant
by Jakub Jelinek, Iyer Balaji and Igor
Zamyatin./dd
Wht? No Aldy Hernandez? I spent the better part of year working on
this. Although perhaps it's better if no one remembers that ;-).
Aldy
can you please make this Cilk Plus support or Full Cilk Plus support
in the title, and then use
Jan Hubicka hubi...@ucw.cz writes:
Hi,
Libreoffice fails to build because ltrans tries to fetch in variable
constructor
that is not shipped there. Fixed thus.
Bootstrapped/regtested x86_64-linux.
Honza
* varpool.c (varpool_node::ctor_useable_for_folding_p): Do not try
to
On 09/09/14 02:16, Richard Biener wrote:
On Tue, Sep 9, 2014 at 2:00 AM, Aldy Hernandez al...@redhat.com wrote:
On 09/05/14 02:00, Richard Biener wrote:
What I have in mind is:
1. Move the FE specific things that come before the call to
finalize_compilation_unit currently in each
On 09/12/14 08:15, Jason Merrill wrote:
On 09/11/2014 08:51 PM, Aldy Hernandez wrote:
- timevar_start (TV_PHASE_DEFERRED);
- timevar_stop (TV_PHASE_DEFERRED);
- timevar_start (TV_PHASE_OPT_GEN);
Why?
TV_PHASE_OPT_GEN is now in compile_file(), where we call
finalize_compilation_unit
On 09/12/14 10:33, Jason Merrill wrote:
On 09/12/2014 01:10 PM, Aldy Hernandez wrote:
TV_PHASE_DEFERRED, on the other hand, is a bit problematic because it
was originally wrapping the code inside LANG_HOOKS_WRITE_GLOBALS, which
will now reside inside the parser (and is thus included
On 09/12/14 10:56, Jason Merrill wrote:
On 09/12/2014 01:48 PM, Aldy Hernandez wrote:
Unless I'm misunderstanding something, validate_phases() verifies that
the numbers add up by looking at the actual string name of the phase,
irregardless of if you timevar_push/pop'ed it:
Yes, but why
this is a longstanding name, but the proposed
is clearer and virtually the same.
OK for mainline?
commit 2705197662689e354fe397abe907ebf3763eae2d
Author: Aldy Hernandez al...@redhat.com
Date: Thu Sep 18 10:06:43 2014 -0600
* cgraph.h, dbxout.c, dwarfout2.c, gimple-fold.c,
lto-streamer
- DECL_ABSTRACT (fn) = 1;
+ DECL_ABSTRACT_P (fn) = 1;
It'd probably make sense to use 'true' now.
I thought about it, but I wanted to change as little as possible, plus I
wanted to follow the same style as what we've been doing for a lot of
the _P macros:
DECL_HAS_VALUE_EXPR_P (t) =
?
Aldy
commit d51576de0a8450634ff7622e4688fd02fc8fcee9
Author: Aldy Hernandez al...@redhat.com
Date: Thu Sep 18 10:35:30 2014 -0600
* dwarf2out.c (decl_ultimate_origin): Update comment.
* tree.c (block_ultimate_origin): Same.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index
of libstdc++ without any
ICEs, all while keeping the guality.exp tests for C at less regressions
than mainline.
Comitting to branch. Whine if in violent disagreement.
Aldy
commit 8face8fdb00474fe3e2375d08eab52726e125b8a
Author: Aldy Hernandez al...@redhat.com
Date: Thu Sep 18 12:37:43 2014 -0600
276bf40161769e0485854576073aff9f35b16300
Author: Aldy Hernandez al...@redhat.com
Date: Thu Sep 18 10:06:43 2014 -0600
* cgraph.h, dbxout.c, dwarfout2.c, gimple-fold.c,
lto-streamer-out.c, print-tree.c, symtab.c, tree-inline.c,
tree-streamer-in.c, tree-streamer-out.c, tree.c, tree.h,
varpool.c: Rename
mainline. Yay.
Committing to mainline.
Thanks.
Aldy
commit 7254ec0893f9b56a0ba78de9eab8895c9582c24b
Author: Aldy Hernandez al...@redhat.com
Date: Thu Sep 18 16:54:39 2014 -0600
* dwarf2out.c (decl_ultimate_origin): Allow checking of
DECL_ABSTRACT.
diff --git a/gcc/dwarf2out.c b/gcc
On 09/18/14 13:55, Jason Merrill wrote:
On 09/18/2014 03:25 PM, Aldy Hernandez wrote:
This patch disables removing of
DW_AT_{declaration,object_pointer,formal_parameter} tags while
generating a DIE for subprograms. Now that we generate dwarf info
early, we will always have an old_die
On 09/22/14 08:17, Michael Matz wrote:
Hi,
On Fri, 19 Sep 2014, Aldy Hernandez wrote:
Michael, I really don't understand the need for this change in your original
patch. I don't know if this was a temporary testing change or what.
I'm pretty sure it was temporary testing, when I still
On 09/18/14 12:39, Aldy Hernandez wrote:
Yeah, sure, either way it's a good cleanup ;).
No strong opinions. Though I think true/false are the way we want folks
to write new code. Given that's the long term direction, might as well
fix that nit for DECL_ABSTRACT_P.
Alright... fixed.
OK
push_cfun() fails when there's no cfun stack. With this patch, we use
set_cfun if not stack is available.
This fixes the 16 Fortran guality regressions.
Now guality tests all pass, for all languages.
Committed to branch.
commit a6f19a625bc6f662db6f23679503458f22721de9
Author: Aldy Hernandez
The problem here is that we are setting __OBJC2__ regardless of what
language we are compiling.
Tested by building a cross cc1/cc1obj for x86_64-unknown-darwin, and
doing the following:
reynosa:/build/trunk-darwin-objc/gcc$ echo | ./cc1obj -E -dM -
-quiet |grep OBJ
#define __OBJC__ 1
currently set __OBJC__ in
libcpp/init.c:
if (CPP_OPTION (pfile, objc))
_cpp_define_builtin (pfile, __OBJC__ 1);
I hope this helps in reviewing the patch.
Thanks.
On 12/04/12 16:25, Aldy Hernandez wrote:
The problem here is that we are setting __OBJC2__ regardless of what
language we
6b366d44e7d30d3a24eda07fcb43fc20e2aa7102
Author: Aldy Hernandez al...@redhat.com
Date: Wed Dec 5 12:06:01 2012 -0600
PR rtl-optimization/55604
* lra-lives.c
* (remove_some_program_points_and_update_live_ranges):
Avoiding division by zero when dumping live range
Adjusted ChangeLog entry as suggested by Jakub on IRC.
OK?
commit ddc4494409331e5a75814a6c8a57aa0646257fb2
Author: Aldy Hernandez al...@redhat.com
Date: Wed Dec 5 08:38:10 2012 -0600
PR target/54160
* config/t-darwin (darwin-c.o): Depend on $(CPP_INTERNAL_H).
* config
On 12/05/12 12:13, Aldy Hernandez wrote:
This is a division by zero ICE.
In the testcase in the PR, both `n' and `lra_live_max_point' are zero. I
have opted to inhibit the dump when lra_live_max_point is zero, but I
can just as easily avoiding printing the percentage in this case.
Let me know
It could work too. Either code is ok to me. The testscase is very rare
and can be achieved only for a small program. So the code speed is not
important. I favor a bit your code as it does not change the code
presented in IRA and LRA which might be unified someday. So if you are
ready to
462e1c25a81bfb575a9113e4d117c5972c827715
Author: Aldy Hernandez al...@redhat.com
Date: Mon Dec 3 13:03:16 2012 -0600
PR rtl-optimization/51771
Revert:
* builtin-attrs.def (ATTR_RETURNS_TWICE, ATTR_TM_NOTHROW_RT_LIST): New.
* gtm-builtins.def (BUILT_IN_TM_START): Add returns-twice attrib
9775b837cf9ece71cbf9560c35c638b3f8c0a778
Author: Aldy Hernandez al...@redhat.com
Date: Fri Dec 7 10:40:25 2012 -0600
PR c++/55513
* semantics.c (cxx_eval_builtin_function_call): Set non_constant_p
after folding.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index 491d97c
On 12/07/12 14:04, Richard Henderson wrote:
On 2012-12-05 15:06, Aldy Hernandez wrote:
PR rtl-optimization/51771
Revert:
* builtin-attrs.def (ATTR_RETURNS_TWICE, ATTR_TM_NOTHROW_RT_LIST): New.
* gtm-builtins.def (BUILT_IN_TM_START): Add returns-twice attrib
On 12/07/12 14:28, Jason Merrill wrote:
On 12/07/2012 01:08 PM, Aldy Hernandez wrote:
+ if (!TREE_CONSTANT (new_call))
+*non_constant_p = true;
You can use VERIFY_CONSTANT here instead. OK with that change.
Jason
VERIFY_CONSTANT is defined further down, so I moved things around.
OK
Hi Richard.
Your last patch for this PR suggested we verify our assumptions wrt a
least common C++ compiler to build trunk with. Since I already had the
offended system at hand (Red Hat Linux 8.0), I decided to investigate a
bit further.
g++ 3.4 builds trunk just fine, but anything prior
As discussed in the thread entitled allow bootstrapping with older
compilers, this patch disallows __attribute__ for GCC 3.4.
Applied as obvious, as you mentioned in the other thread.
Thanks.
commit 370a6a8ddc628924c1deedf752ea9fc9a058d5cc
Author: Aldy Hernandez al...@redhat.com
Date: Tue
As discussed earlier, removing the union brings happiness to older g++'s.
Committed as obvious, per your previous comment.
commit 5d215dbbe1c37aaf98307cb71d250222fb802114
Author: Aldy Hernandez al...@redhat.com
Date: Tue Dec 18 09:21:28 2012 -0600
PR other/54324
* tree-ssa
On 12/12/12 03:33, Richard Biener wrote:
On Tue, 11 Dec 2012, Aldy Hernandez wrote:
4. Type checking as part of a `for' initializer segfaults on g++ 3.2:
for (type = TYPE_MAIN_VARIANT (blah); )
The only reasonable thing I could think of, was disabling the tree
checking
692859f796d90eebd97ad97ad872bbb7b7f49c12
Author: Aldy Hernandez al...@redhat.com
Date: Thu Jan 10 11:58:37 2013 -0600
PR target/55565
* gcc.target/powerpc/ppc-mov-1.c: Update scan-assembler-not
regex.
diff --git a/gcc/testsuite/gcc.target/powerpc/ppc-mov-1.c
b/gcc/testsuite/gcc.target
?
commit 61ceeb130c2c2c342f19e716397ffddd212a0b32
Author: Aldy Hernandez al...@redhat.com
Date: Thu Jan 10 11:58:37 2013 -0600
PR target/55565
* gcc.target/powerpc/ppc-mov-1.c: Update scan-assembler-not
regex.
diff --git a/gcc/testsuite/gcc.target/powerpc/ppc-mov-1.c
b/gcc
Janis Johnson janis_john...@mentor.com writes:
Richard,
In December I submitted a patch to replace ftest*.c in gcc.target/arm with
compile-only tests: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg01339.html.
There has been no response to the patch.
One reason for the replacement is that
Andrew Pinski andrew.pin...@caviumnetworks.com writes:
+gimple interal representation of pointer addition, and for various
s/interal/internal/
fcac0360de909e6d96fe005a3012139d487d2db8
Author: Aldy Hernandez al...@redhat.com
Date: Mon Feb 11 15:51:24 2013 -0600
PR target/52555
* tree.h (struct tree_optimization_option): New field
target_optabs.
(TREE_OPTIMIZATION_OPTABS): New.
(save_optabs_if_changed
?
commit ee1f2aebe23fe0d5cecfdfde9822ef681bf6ef0c
Author: Aldy Hernandez al...@redhat.com
Date: Mon Feb 11 15:51:24 2013 -0600
PR target/52555
* tree.h (struct tree_optimization_option): New field
target_optabs.
(TREE_OPTIMIZATION_OPTABS): New
avoiding recomputing init_all_optabs() in save_optabs_if_changed:
+ if (TREE_OPTIMIZATION_OPTABS (optnode))
+return;
Is this still part of the plan?
How is this revision?
commit 48c1f4d243f81ca975b2aae34773b91ef6cbd8ca
Author: Aldy Hernandez al...@redhat.com
Date: Mon Feb 11 15:51:24 2013 -0600
Richard.
I made all the changes you suggested.
I also changed other instances of s/this_target_optabs/this_fn_optabs/
which I forgot in the previous iteration. And I also changed
save_optabs_if_changed() to use this_fn_optabs, since init_all_optabs()
will generate the optabs into
Sorry, just noticed:
+ /* If the optabs changed, record it in the node. */
+ if (memcmp (tmp_target_optabs, default_target_optabs,
+ sizeof (struct target_optabs)))
This should be this_target_optabs rather than default_target_optabs.
Nothing but target code and initialisers
SWITCHABLE_TARGET to 0/1, so there should never be an
undefined symbol. If you'd prefer the ifdef, I can grudgingly change it
back :).
[Richard, unfortunately there are some mips specific changes.]
How does this look y'all?
+2013-02-15 Aldy Hernandez al...@redhat.com
+ Jakub Jelinek
on GC allocated memory is wrong. Just remove the comment
and if and XDELETE lines.
And this is just embarrassing...fixed. Thanks.
Retesting the attached patch.
+2013-02-15 Aldy Hernandez al...@redhat.com
+ Jakub Jelinek ja...@redhat.com
+
+ PR target/52555
+ * genopinit.c
Hi folks.
The following is a test harness for testing atomicity problems and data
races in multi-threaded environments. Please see the README file in the
patch below, which describes the use of GDB to test in-between states in
a possibly threaded execution.
I would like to use this branch
The following patch adds the --param(eters) needed to tweak the
optimizers into allowing or disallowing data races in cross-thread
visible data.
There will be additional flags added later to make these parameters
available to the common user. It has been suggested to use
-fmemory-model=xxx,
This test is inspired by PR 48124.
[Jakub, let me know if you find any additional variations on this theme.]
In the C++ memory model, non contiguous bitfields are distinct memory
locations and cannot be accessed by and/or magic if we introduce data races.
In the test below, we can trigger
On 03/24/11 14:58, Richard Henderson wrote:
On 03/24/2011 10:33 AM, Aldy Hernandez wrote:
In the example below we usually hoist global into a register or
temporary to avoid reading from it at each step. This would cause a
race if another thread had modified global in between iterations
[Language lawyers, please correct me if I have mis-interpreted the
upcoming standard in any way.]
In the C++ memory model, contiguous bitfields comprise a single memory
location, so it's fair game to bit twiddle them when setting them. For
example:
struct {
unsigned
The memory model is not implementable on strict-alignment targets
that do not have a byte store operation. But we previously said that ;)
Yes. I think we should issue an error when we have such a target and
the user tries -fmemory-model=c++0x. However, how many strict-alignment
targets
But well, I guess the thing I don't like about the standard is that it makes
people that have started to be somewhat aware about threading issues
_less_ aware of them by providing some false safety to them. It
really smells like a standard designed for a very high-level language
where people
(5) Do we agree that all such cpus use a byte-granular modification mask?
Now, as of (0) I might agree to disregard the original Alpha, but as the
embedded world moves to SMP I'm not sure we can disregard
non-cache coherent NUMA setups or even CPUs without a byte store.
As per 5, it
/wiki/Atomic/GCCMM;C++ memory model/a/dt
+ ddThis branch is for the implementation of the C++ memory model.
+ Patches for this branch should be marked code[cxx-mem-model]/code
+ in the subject line. The branch is maintained by Aldy Hernandez./dd
+
dtdwarf4/dt
ddThis branch is for support
On 04/04/11 08:30, Aldy Hernandez wrote:
mind updating svn.html with a short note on this new branch?
Whoops, sorry about that.
Applied attached patch.
Sorry, wrong patch. This is the correct one.
Index: svn.html
===
RCS
[Jason, Benjamin: It'd be nice to get input from y'all, since you are
more intimately involved with the standard. I want to make sure I'm not
misunderstanding things.]
Hopefully a non-controversial feature, but given my luck, I doubt it :).
Here are two additional tests to verify our atomic
I've gotten tired of the false positives in the current testsuite for
the cxxbitfield* tests. The tests are highly dependent on assembly
output, and currently they only work on x86-64/x86-32 (mostly).
I have rewritten the tests to be platform agnostic, by using the
GDB/thread testing
off the top of my head, maybe something like one of the following:
step-through
gdb-invoked
side-effects
simulate-thread
simulate-thread or step-through sound fine. I'd vote for
simulate-thread, but really-- whatever...
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01272.html
First, thanks so much for tackling this review. I don't think anyone's
overly enthusiastic about reviewing dejagnu crap^H^H^H^Hcode.
On 10/04/11 08:43, Aldy Hernandez wrote:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01272.html
So others have already mentioned the name memmodel as being
On 10/07/11 17:50, Mike Stump wrote:
On Oct 7, 2011, at 2:52 PM, Aldy Hernandez wrote:
First, thanks so much for tackling this review. I don't think anyone's overly
enthusiastic about reviewing dejagnu crap^H^H^H^Hcode.
I'll review it. :-) The last version looks fine to me, watch out
Hi folks.
This was a change Andrew had made to the simulate-thread framework to
avoid infinite loops in hostile threads. I forgot to merge this in my
original submission, and am doing so now.
The original patch is here:
http://permalink.gmane.org/gmane.comp.gcc.patches/247678
My patch is
Nothing major to report. I found a small buglet in
gcc/testsuite/g++.dg/dg.exp that is left over from the memmodel -
simulate-thread rename.
I also found that trunk does not have the following change to
g++.dg/dg.exp and I will submit this as a follow up (to trunk).
Committed to branch.
Several ICEs in the TM tests on C++, but I think they are old. C TM
tests work except some missing optimizations (old failures too).
c-c++-common/tm/wrap-[12].c fail on C++, but not on C:
wrap-1.c:5:57: error: 'transaction_wrap' argument not an identifier
I believe this is an old error too?
(I
Found this while testing the branch on ia64. The call to
expand_val_compare_and_swap() above returns NULL_RTX when it can't find
a suitable instruction.
OK for branch?
* optabs.c (expand_atomic_load): Handle a NULL target.
Index: optabs.c
These operations don't exist on x86-32 bits, and when running multilibed
tests, the target is still x86_64-unknown-linux-gnu but the target is
32-bits when using -m32.
The following change checks that we are actually running in 64-bits
before assuming sync_int_128 or sync_long_long exist on
On 10/20/11 15:56, Andrew MacLeod wrote:
On 10/20/2011 04:54 PM, Aldy Hernandez wrote:
Found this while testing the branch on ia64. The call to
expand_val_compare_and_swap() above returns NULL_RTX when it can't
find a suitable instruction.
OK for branch?
yes. btw, did you audit the other new
On 10/21/11 11:08, Andrew MacLeod wrote:
On 10/21/2011 11:28 AM, H.J. Lu wrote:
On Fri, Oct 21, 2011 at 5:11 AM, Andrew MacLeodamacl...@redhat.com
wrote:
X32 has native int64 and int128.
I presume there is no atomic support for int128 though, and thats what
'condition
On 10/21/11 15:46, Joseph S. Myers wrote:
On Fri, 21 Oct 2011, Aldy Hernandez wrote:
X32 uses x86-64 instruction set with 32bit pointers. It has the same
atomic support as x86-64 and has atomic support for int128.
Oh, you aren't talking about 32 bit, but a 32 bit abi on a 64 bit machine
Bootstrapped and tested on i686 with same number of errors.
Sorry to ask you to run more tests, but can you also test x86-64? If
there are no regressions on x86-64 either, OK.
Aldy
This works for me. Do you agree?
It looks good to me.
OK, will commit.
Thanks guys.
On 10/24/11 10:40, Aldy Hernandez wrote:
Bootstrapped and tested on i686 with same number of errors.
Sorry to ask you to run more tests, but can you also test x86-64? If
there are no regressions on x86-64 either, OK.
As discussed off-line, I'll run x86-64 tests for you since you don't
The merge broke base/complete dtor transactional clones that we
originally implemented here:
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00590.html
First, ipa_tm_execute() was putting __comp_dtor's into tm_callees, which
wasn't happening pre-merge. Handling this __comp_dtor caused an ICE
Ho hum, more patches on our way to mergeability.
This seems to be more fallout from the last merge. There's an apparent
discrepancy between what we think is valid gimple in
ipa_tm_insert_gettmclone_call() and what verify_gimple_call() believes
is true.
This, along with other patches I have
Here we have a testcase that affects both the C++ memory model and
transactional memory.
[Hans, this is caused by the same problem that is causing the
speculative register promotion issue you and Torvald pointed me at].
In the following testcase (adapted from the PR), the loop invariant
On 04/13/12 18:22, Boehm, Hans wrote:
-Original Message-
From: Aldy Hernandez [mailto:al...@redhat.com]
Sent: Thursday, April 12, 2012 3:12 PM
To: Richard Guenther
Cc: Andrew MacLeod; Boehm, Hans; gcc-patches; Torvald Riegel
Subject: [PR tree-optimization/52558]: RFC: questions
On 04/13/12 03:46, Richard Guenther wrote:
On Fri, Apr 13, 2012 at 12:11 AM, Aldy Hernandezal...@redhat.com wrote:
Richard. Thanks so much for reviewing and providing an alternative
approach, which AFAICT provides superior results.
A similar effect could be obtained by keeping a flag
1 - 100 of 2276 matches
Mail list logo
