attached fix the ia64 failure?
commit 6c40c8f011bbd09ea92749f3925db83f249baf74
Author: Aldy Hernandez
Date: Sat Jun 6 06:48:40 2015 -0400
* dwarf2out.c (gen_lexical_block_die): Initialize stmt_die.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 2e3bee3..23cf120 100644
-
The debug-early work has been merged into mainline.
There is a known Ada failure which Eric B. knows about and approved, and
for which there is an appropriate FIXME note in the Ada sources:
+FAIL: gnat.dg/specs/debug1.ads scan-assembler-times DW_AT_artificial 17
There is also a known regressi
On 05/08/2015 01:51 AM, Richard Biener wrote:
Did you see if --with-build-config=bootstrap-lto still works?
Just did on x86-64 Linux. Bootstrap succeeds without any problems.
While doing the LTO work I wondered why you have the late_global_decl
loop in toplev.c:compile_file at all (well, ma
On 05/06/2015 04:22 AM, Richard Biener wrote:
On Wed, May 6, 2015 at 12:33 AM, Aldy Hernandez wrote:
Gentlemen!
I believe I have done as much as is reasonable for a merge, but I'd like to
get your opinion before I post a huge patch to the list.
The branch bootstraps with one regressi
Gentlemen!
I believe I have done as much as is reasonable for a merge, but I'd like
to get your opinion before I post a huge patch to the list.
The branch bootstraps with one regression in GCC
(gcc.dg/debug/dwarf2/stacked-qualified-types-3.c) and none for GDB.
The GCC regression is a missed
There was one minor regression which I've fixed.
Tested on x86-64 Linux with the GCC and GDB testsuites.
Next on my plate is (finally) a full bootstrap now that GCC's
guality.exp, dwarf2.exp, and debug.exp are down to 1 regression versus
mainline. And finally... submitting the branch for revi
Gentlemen:
Since we pick global symbols to be emitted early from the symbol table,
we miss out on DECL_EXTERNAL's because they never appear in the symbol
table:
[rest_of_decl_compilation]:
else if (TREE_CODE (decl) == VAR_DECL && !DECL_EXTERNAL (decl)
&& TREE_STATIC (decl))
v
Andrew Haley writes:
> On 12/21/2014 02:38 AM, Bruce Korb wrote:
>> Shouldn't the configure step have made config.h?
>
> It's probably because you are building in srcdir. That is not
> supported.
Hmm, newbies run into this often enough that I wonder whether we should
just error out from the con
On 10/15/14 00:55, Richard Biener wrote:
On Tue, Oct 14, 2014 at 10:07 PM, Aldy Hernandez wrote:
On 10/14/14 06:21, Richard Biener wrote:
On Tue, Oct 14, 2014 at 2:48 AM, Aldy Hernandez wrote:
Another similar issue I've seen is handling DW_TAG_lexical_block
(gen_lexical_bloc
Another similar issue I've seen is handling DW_TAG_lexical_block
(gen_lexical_block_die). Ideally we should generate the
DW_TAG_lexical_block and the corresponding locals in early dumping, and
then fill in the high/low attributes of the lexical block the second
time around. We would need a has
On 10/14/14 06:21, Richard Biener wrote:
On Tue, Oct 14, 2014 at 2:48 AM, Aldy Hernandez wrote:
Gentlemen, your feedback would be greatly appreciated!
I was investigating why locals were not being early dumped, and realized
Michael's patch was skipping decls_for_scope() u
Gentlemen, your feedback would be greatly appreciated!
I was investigating why locals were not being early dumped, and realized
Michael's patch was skipping decls_for_scope() unless
DECL_STRUCT_FUNCTION->gimple_df was set. I assume this was to wait
until location information was available. T
On 08/18/14 07:31, Richard Biener wrote:
On Mon, Aug 18, 2014 at 12:46 PM, Richard Biener
wrote:
On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
For the rest them on the floor instead of ICEing in dwarf2out.c. */
Should that read "For the rest, drop them on the
Isn't the only real solution: to generate this kind of DIEs earlier
(maybe already immediately after parsing) and stream them?
Ultimately yes, and that's what I hope to work on, but I was mostly
curious because at stream out time, the information *is* there, and we
silently dropped it.
Ald
So... I've been getting my feet wet with LTO and debugging and I noticed
a seemingly unrelated yet annoying problem. On x86-64,
gcc.dg/guality/pr48437.c fails when run in LTO mode.
I've compared the dwarf output with and without LTO, and I noticed that
the DW_TAG_lexical_block is missing from
On 10/09/13 13:32, Iyer, Balaji V wrote:
Is it OK for trunk?
I would prefer that a consumer of this library be in place before you
commit. That is, until cilk_spawn/sync/etc go in.
Hi folks.
In order to facilitate the contribution and possible merging of the
cilkplus work into mainline, I have created a new git branch
(cilkplus-merge). I have also created a wiki page where we (Balaji and
myself) will keep a status of the work:
http://gcc.gnu.org/wiki/cilkplus-
Uday Khedker writes:
> I think we need to come out of the "documentation" mindset. No amount
> of conventional documentation is going to help. What we need is a
> training material that included well defined assignments.
FWIW, I initially learned GCC by an internal training program Jeff Law
devi
On 09/05/12 12:09, Iyer, Balaji V wrote:
I can't speak for the rest of the community, but I think items 1-12 are useful
for
GCC (elemental functions, SIMD annotations, and array notations for C/C++),
regardless of any language extensions. Perhaps you could provide examples on
these as a start
On 08/30/12 15:39, Iyer, Balaji V wrote:
Hello Everyone,
The Cilk-Plus branch is feature-complete. Programs using Cilk Plus
constructs get great performance on vector and multicore hardware. Programs
that don't use the new language features (enabled by a -fcilkplus flag) see no
change.
In theory we should be able to do multiple "LTO" passes. So we could do
a.c a.o
... -> -> WPA -> LTRANS and TM lowering -> WPA -> LTRANS and RTL
expand
x.c x.o
Thus, after a first wave of WPA and LTRANS in non-lowered TM we can,
after the TM lowering in the first LTR
a) If a user provides a builtin implementation to LTO, it is discarded,
since by design LTO prefers builtins to user-provided versions of them. In
LTO, builtins are their own prevailing decl. There is an enhancement
request PR here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51997
Hi gentlemen.
I am looking again at LTO + TM. The goal is to be able to link with the
implemented _ITM_* functions in libitm.a, and have them inlined into the
transaction code when profitable.
To refresh everyone's memory, the original problem was two-fold:
a) If a user provides a builtin i
On 05/31/12 15:44, Aldy Hernandez wrote:
Hello gentlemen.
Would it be ok to backport the fix for PR52558 into the 4.7 branch? This
PR is the store data race patch I have been iterating with Richi. Doing
so will avoid critical data races for both TM and the C++ memory model.
The code is all
Hello gentlemen.
Would it be ok to backport the fix for PR52558 into the 4.7 branch?
This PR is the store data race patch I have been iterating with Richi.
Doing so will avoid critical data races for both TM and the C++ memory
model.
The code is all predicated by flag_tm or !PARAM_VALUE
(PA
On 03/19/12 12:28, David Edelsohn wrote:
On Wed, Mar 14, 2012 at 10:08 AM, Steven Bosscher wrote:
Hello,
The rs6000 and cr16 backends and unwinding code have a define for the
DWARF frame register for pre-GCC3 compatibility
(PRE_GCC3_DWARF_FRAME_REGISTERS):
gcc/doc/tm.texi.in:@defmac PRE_GCC3_
* Bug 51752 - trans-mem: publication safety violated
I'm working on this.
Linus Torvalds writes:
> Seriously - is there any real argument *against* just using the base
> type as a hint for access size?
If I'm on the hook for attempting to fix this again, I'd also like to
know if there are any arguments against using the base type.
On 12/21/11 11:06, Patrick Marlier wrote:
Wonderful! Thanks Aldy.
On 12/21/2011 09:11 AM, Aldy Hernandez wrote:
* ICE when lto1 does not have -fgnu-tm and object file uses TM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51280
I believe I wasn't able to reproduce this.
Arg really! Fo
On 01/09/12 04:20, Torvald Riegel wrote:
Looking at Patrick's old list, the following bugs are still open
[trans-mem] save/restore of thread-local data in nested txns is missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49581
Aldy, you wanted to take a look. Were you able to repr
* Stack save/restore not working? -> XFAIL testcases
Related to this:
ICE: verify_gimple failed: invalid rhs for gimple memory store with
-fgnu-tm --param tm-max-aggregate-size=32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51472
Proposed fix, waiting for review.
[trans-mem] save/restore of
The TM branch has been merged into trunk. No regressions or problems
when testing on x86-64 Linux.
Thanks to Torvald and Richard for all their hard work this past week
(and prior!). And thanks to all the branch reviewers.
If anyone needs me, I'll be enjoying my time in Honolulu, so don't bo
No anomalies. No regressions.
I will now post the full patchset I would like to post to trunk.
I suppose we can freeze for the TM merge once we leave stage1 (thus,
in a few hours).
If you are ready by then, of course, and the tree isn't too broken.
Richard.
Fine by me. In the meantime we will stabilize things on the branch,
merge from trunk, run tests, and have a patch ready to be ap
Dear Release Managers...
We're pretty much done with the merge blockers, and even suggestions
that weren't blockers :). The only outstanding patch review is a
cleanup by Richard Henderson that is waiting for Richi's review here:
http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01033.html
I am s
Could you please fix up whitespace in the patch, at least leading tabs
and trailing whitespace?
On the patch it is easy to do, something like:
sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
\{32\}/+\1\t\t\t\t/;s/^+\([\t]*\) \{16\}/+\1\t\t/;s/^+\([\t]*\)
\{8\}/+\1\t/;s/^+\(.*[^[:b
We want to look at proper patch submissions not at websites that change
from time to time. I really don't know what you take issue with, or where
the difficulty is. patch submission via gcc-patches@ is a requirement
since forever, not something arbitrarily imposed on specifically you to
annoy
Aldy, what folks are asking for is reasonably contained patches from
the branch that can be reviewed. Ideally they could be installed
independently, but it's not strictly necessary.
I already did so:
compiler/
libitm/
libstdc++-v3/
misc/
toplevel/
The ChangeLog's are at the top. The testsu
Index: gcc/c-opts.c
===
--- gcc/c-opts.c(.../trunk) (revision 0)
+++ gcc/c-opts.c(.../branches/transactional-memory) (revision
180773)
@@ -0,0 +1,1773 @@
+/* C/ObjC/C++ command line option handling.
+ Copy
Reviewable patches as in what goes in gcc-patches? Or do you want something
else?
Reviewable branch merge patch(es). You can't expect everyone to
follow all development branches that may or may not end up being merged.
Is what I posted not in a way that can be reviewed? Did you download
Have you ever posted the patch, or only made it available via the website?
Have you not seen the last 3 years of patches to gcc-patches? They're
prefixed by [trans-mem]. Perhaps you're filtering them out.
Just scanning
http://quesejoda.com/redhat/tm-branch-diffs-from-trunk-at-180744/comp
Could you please fix up whitespace in the patch, at least leading tabs
and trailing whitespace?
On the patch it is easy to do, something like:
sed 's/^+\([\t]*\) \{64\}/+\1\t\t\t\t\t\t\t\t/;s/^+\([\t]*\)
\{32\}/+\1\t\t\t\t/;s/^+\([\t]*\) \{16\}/+\1\t\t/;s/^+\([\t]*\)
\{8\}/+\1\t/;s/^+\(.*[^[:b
Is this necessary for the entire patch, or just the parts that touch
existing parts of the toolchain. For example, do you want me to run
this on libitm/, etc? I'm really trying to minimize changes (even
whitespace stuff) at the last minute, but if you think it's
imperative, I will do so.
Wel
I have separated out a master patchset for the cxx-mem-model work:
http://quesejoda.com/redhat/cxx-mem-model-diffs-from-trunk-at-180790/
When would be a good time to ask for a trunk freeze/slush to do a merge?
Aldy
I remember at least seeing middle-end pieces in alias analysis.
Yes, but they're mechanical changes. Do you mean these?:
@@ -1182,6 +1182,8 @@ ref_maybe_used_by_call_p_1 (gimple call,
case BUILT_IN_MEMPCPY:
case BUILT_IN_STPCPY:
case BUILT_IN_STPNCPY:
+case BU
I'd like to see some breakdown into subsystem patches. Can someone provide
those together with changelog entries?
I am doing another merge from trunk->branch, and will post a series of
patches by subsystem. I will do so after the merge is complete and tested.
Have you looked at those diffs, there's a fair amount of unrelated
Will clean up.
crud in there... It might help to break the blob into more easily
understood hunks for actual submissions. ie, runtime bits (libitm),
changes to existing runtime stuff, compiler proper, testsuite bits, etc.
Aldy, Richard, is there a patchset or master patch I could read?
I have made current diff as of today:
http://quesejoda.com/tm-branch-latest.bz2
This is somewhat of a me-too message for the transactional-memory work.
We would also like it to be considered for merging with mainline
before the end of stage1.
We have a kept a wiki here:
http://gcc.gnu.org/wiki/TransactionalMemory
What it is
==
From the wiki...
Transactional me
> It does not address other missing aspects of the c++ memory model. In
> particular, bitfields are still not compliant with not introducing new
> potential data races.
Can we treat this as a bugfix to be done during stage2? There is
already some support in mainline, but it performs lousy on an
This was very painful, and it's still not over. We hadn't merged in
almost 1.5 years, and we're paying for it now...
I managed to resolve all the conflicts, and bootstrap the compiler,
which is rather amazing given the size of the changes. There are still
over 16 compiler failures in gcc.dg/
Jakub Jelinek writes:
> In particular, is transactional-memory branch mergeable within
> a month and half, at least some parts of cxx-mem-model branch,
> bitfield lowering? What is the status of lra, reload-2a, pph,
Torvald and I are looking into getting things merge read, but...
The main prob
Not that I'm abandoning the transactional memory party, but I'll also be
spending some cycles on the C++0x memory model work, which is an
offshoot of the atomics work Andrew Macleod has been working on
(http://gcc.gnu.org/wiki/Atomic).
I have added a link to the memory model work from the main
> > ... a slightly more sophisticated variant of b) would be using
> > uint64_t for 64-bit targets and uint32_t for 32-bit targets, should
> > make everybody happy.
>
> There's a correctness issue in the library interface -- there's no
> clean way to handle that value overflowing. Rather than mak
> > > Are you suggesting we remove the entire code path here:
> > >
> > > ?/* Try harder to get a rtl. ?If this symbol ends up not being emitted
> > > ? ? in the current CU, resolve_addr will remove the expression referencing
> > > ? ? it. ?*/
> > >
> > > ??
> >
> > Yes.
>
> That will very much p
> > ? ? rtl = DECL_RTL (decl);
> > ? ? /* Reset DECL_RTL back, as various parts of the compiler expects
> > ? ? ? ?DECL_RTL set meaning it is actually going to be output. ?*/
> > ? ? SET_DECL_RTL (decl, NULL);
> >
> > ... why do this in the first place? ?Is this an issue for all decls or just
> > f
> I guess best would be to make sure no new alias set is created in these
> places. Perhaps
> int save_strict_aliasing = flag_strict_aliasing;
> flag_strict_aliasing = 0;
> rtl = DECL_RTL (decl);
> flag_strict_aliasing = save_strict_aliasing;
> in both places?
Remember when I said I had come up w
Hi folks.
I am debugging a bunch of Fortran -fdebug-compare failures on the
testsuite, all of which stem from symbols ending up on different alias
set slots. Notice the 2 versus 3 discrepancy below:
< (insn:TI# 0 0 a.f90:3 (set (mem/c/i:SI (symbol_ref:DI ("i.0.1535")
[flags 0x2] ) [2 i.0+0 S4 A3
libitm.so won't build on ia32 because of an undefined reference to
__sync_add_and_fetch_8.
This is the build failure Pearly encountered here:
http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01201.html
What happens is that we try to do a __sync_and_fetch() on global_tid,
which is of type _IT
Nothing major.
Two minor changes:
Edge frequencies are now compared with BB frequencies in
verify_cgraph_node(). This showed an inconsistency in
the edge created in ipa_tm_insert_gettmclone_call(). Fixed.
The function free_lang_data():tree.c no longer runs for all front-ends,
so lang_hooks.dec
> This part is ok.
Committed.
> > (ipa_tm_transform_calls_1): Rename from ipa_tm_transform_calls.
> > Only process one block.
> > (ipa_tm_transform_calls): Iterate through CFG and call helper
> > function.
>
> This part isn't. As we discussed on IRC, you're missing a check
> for
> I don't think that's true at all. You showed that the walking was
> incorrect; I don't see you you can now argue that it is correct,
> regardless of inlining and jump threading.
>
> All one needs to create the cfg that exhibits the problem is
> multiple exits from the transaction. It's not ter
Hey!
With my last patch, we only have 3 instances of dominator tree walks
left in the tree, all in the TM ipa pass.
I believe we can leave those as they are, since the TM ipa pass runs
early enough that nothing has altered control flow such that
code outside of a transaction ends up inside a tran
> Certainly better. But I fail to see why a different location would be
> better than the original here. I assume all tokens have a correct initial
> location. Then why is for example for int i; in (int) i the location of
> the conversion a better location than the one of i in the folded result
> That wasn't my question.
>
> tem = fold_build2_loc (loc, code, type,
> fold_convert_loc (loc, TREE_TYPE (op0),
> TREE_OPERAND (arg0, 1)), op1);
> protected_set_expr_location (tem, loc);
>
> here tem is built by
> > ? ? ?tem = fold_build2_loc (loc, code, type,
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? fold_convert_loc (loc, TREE_TYPE (op0),
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? TREE_OPERAND (arg0, 1)), op1);
> > ? ? ?protected_set_expr_location (tem, loc);
> >
> > When --enable-checking=fold, fold verifi
Hi folks.
In this PR the problem is that a call to fold_build2_loc() returns one
of the original arguments unchanged. In the code below we take this
result and change its location before returning it.
tem = fold_build2_loc (loc, code, type,
fold_convert_loc (lo
Hi folks.
Fold needs some serious surgery to make it location friendly. I'm
currently revamping the whole thing to take locations, so if you're
thinking of adding locations to any of the functions, please hold off
until I'm done, to avoid duplication of work as well as a conflict
nightmare.
Some
> ../../gcc/gcc/config/i386/winnt.c: In function ?i386_pe_encode_section_info?:
> ../../gcc/gcc/config/i386/winnt.c:288: error: too few arguments to
> function ?make_decl_one_only?
make_decl_one_only expects one argument, and that's what's being fed.
Could you please debug this and find out what's
> Your committal of r148442 has caused an ICE during the build of libgcc
> for targetting win64:
I have this pending patch, which may or may not fix this.
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg01113.html
Can you try and see if it fixes it? Otherwise, can you find out where
the compiler i
oliver.kell...@t-online.de (Oliver Kellogg) writes:
> Anybody else seeing this?
>
> ‘lower_try_finally_switch’:
> ../../../SOURCES/gcc/gcc/tree-eh.c:1350:5: error: ‘tf_loc’ may be used
> uninitialized in this function
Funny, this was never picked up in any of my bootstraps, but it is
indeed a bug
> And now you broke PowerPC and most other targets that call build_decl:
Most other targets? You mean *every* target that uses build_decl.
Oops, sorry about that.
The patch below fixes it. I can't do a bootstrap (I can't find the PPC
machine I have access to, and everyone seems to be in a hurry
> Nope, I just meant that you presumably had every right to do so and should
> have felt free to exercise it because merging a branch justifies asking for a
> freeze.
Ok, I was not aware of that. My apologies. For some reason I thought
only GWP folks (or thereabouts) could ask for a freeze. I
On Sat, Jun 13, 2009 at 01:51:42AM +0100, Dave Korn wrote:
> Aldy Hernandez wrote:
> > Hi folks.
> >
> > At the last minute Ian got a patch in that touched a bunch of places
> > that I was also changing. I resolved the conflicts, and bootstrapped
> > and tes
Hi folks.
At the last minute Ian got a patch in that touched a bunch of places
that I was also changing. I resolved the conflicts, and bootstrapped
and tested for C and C++. Unfortunately, people kept committing stuff
that caused conflicts, so I broke down and committed after a minor C/C++
boots
On Thu, Jun 11, 2009 at 03:09:48PM +0100, Jonathan Wakely wrote:
> 2009/6/5 Jonathan Wakely:
> > 2009/6/5 Aldy Hernandez:
> >>
> >> Which test is this? ?Can you send it to me?
> >
> > It tests a header that isn't checked in yet, so sending the test alon
On Fri, Jun 05, 2009 at 12:09:57AM +0100, Jonathan Wakely wrote:
> 2009/5/20 Aldy Hernandez:
> >>
> >> My only worry is that the testsuite may confuse column and line
> >> numbers and pass/fail tests because of it.
> >
> > Janis has a patch for the tes
On Wed, May 20, 2009 at 04:39:00PM +0200, Manuel L?pez-Ib??ez wrote:
> 2009/5/20 Aldy Hernandez :
> > Hi folks.
> >
> > Before I merge the diagnostics branch I'd like to enable it on the
> > testsuite to get us all in the habit of at least being aware of columns
Hi folks.
Before I merge the diagnostics branch I'd like to enable it on the
testsuite to get us all in the habit of at least being aware of columns.
Joseph Myers suggested enabling it in the compiler instead of the
testsuite. Are there any big objections to this?
Aldy
Hi Tom. Hi folks.
Imagine:
enum e {
E5 = INTMAX + 1,
^ column 15.
};
This addition will trigger an overflow warning in the C FE. However, the
location of the '+' will not be column 15 as expected, but the
pre-processed column number (19):
E5 = 2147483647 + 1,
> In addition, we need to consider the interests of translators, who need
> some time before a release to translate new and changed messages without
Ah. Agreed.
Another thing. Patches to the branch should be tested against the GCC
regression suite *and* the GDB testsuite. Assume any upcoming
Hi folks.
Though I would have preferred to work in mainline with the appropriate
maintainers (Joseph, et al) approving my patches, there seems to be no
way I can limit the invasiveness of my diagnostics work... even though
it's technically a regression and/or bug fix. It can't make it to 4.4,
wit
> * In the near future, make -fdiagnostics-show-caret the default at
> least while in experimental mode or at least during stages1 and 2.
> When making a release -fno-diagnostics-show-caret would be the
> default. Do this through a configure option that sets the default.
>
> * In the far away futu
> Then we are not going to get correct locations ever. New users do not
> read the manual. Neither old users do. New functionality disabled by
> default will be lost for both. I am fairly sure that a significant
> percentage of GCC developers (not just users) do not know about
> -fdiagnostics-show-
> There are various issues that would need to be addressed to have
> decent caret diagnostics:
Agreed. I think having caret diagnostics in place is a good first step,
if only because it'll make debugging of column diagnostics easier.
After this, we can modify the testsuite machinery to test colum
> Aldy> 1. beginning/ending locations functionality as Joseph suggests.
> Aldy> 2. make sure the parsers pick the proper token/location.
> Aldy> 3. error reporting machinery
>
> Aldy> How does this sound?
>
> It sounds good to me. #1 might be hard, I have not looked into it.
Well, we can alwa
> If you're interested in working on this, I think one way to do it
> would be to start with a parser and make sure it always picks the
> proper token from which to extract a location. This is a reasonable
> amount of work, and unfortunately much of it would have to be complete
> before we could e
Hi folks.
I'm looking at 3544[123] and 35742, which are all related to
pp_c_expression not handling complex expressions, so we can't display
correct error messages for statement expressions, etc:
({break;})()
The error here is currently:
#'goto_expr' not supported by pp_c_expression#'
On Mon, Jul 28, 2008 at 10:38:43AM -0400, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Aldy Hernandez and Jakub Jelinek as GIMPLE maintainers.
>
> Please join me in congratulating Aldy and Jakub on their new role.
&
> In terms of regressions versus mainline, the only regressions introduced by
> tuples wrt mainline are the matrix-reorg pass that still has not been
> converted. It also fixes 4 libstdc++ testcases that are currently broken
> in trunk:
Apart from the matrix-reorg regressions, there are the Di
> I think that someone, though, should be committed to fixing this pass ASAP
> after it's checked in; waiting until late August to fix it seems bad. Is
> there someone else who can commit to working on it as a high priority after
> the main tuples checkin?
I would obviously vote in favor of re
Nothing interesting except less regressions. Yay.
I have merged mainline @137837 into the branch.
Jakub reports:
I don't have a testsuite_summary log from after the PRE commit but
before this merge, only summary from yesterday. There are many tests
fixed (most of them likely because of the PRE merge) and several
On Mon, Jul 14, 2008 at 02:28:51PM -0700, Diego Novillo wrote:
> Jakub,
>
> You've been doing great work on the branch, so Aldy and I think that
> you don't really need patch approval for branch patches anymore. So,
> from now on, feel free to commit your patches without waiting for an
> explicit
> "Diego" == Diego Novillo <[EMAIL PROTECTED]> writes:
> are OK. If you are creating a bugzilla report, please add my address
> to the CC field.
Me too please.
Aldy
Hey there.
Frequently we want to create a new sequence that contains one element.
This is especially common when wrapping things with a BIND or in a TRY
block.
I'm tired of typing the same thing over and over.
How about a convenience function like this?
Index: gimple.h
=
On Fri, Mar 28, 2008 at 08:48:12AM -0400, Diego Novillo wrote:
> Folks, I need to freeze the branch for a few hours. The overnight
> tester returned many new failures that I need to analyze. Please
> refrain from checking in anything until I unfreeze the branch.
Grrr. I hope it wasn't me. I di
> Yes, the gimplifier often makes several passes over the same trees to get
> them completely lowered. cp_gimplify_expr is a subroutine of the
> gimplifier.
Good, I just wanted to make sure I wasn't off my rocker or anything.
> Sure. Another alternative would be to leave the calls to gimplify
Hi Jason. Hi folks.
I'm in the process of converting the C++ FE to tuples. In doing so I
have noticed that the C++ FE will frequently gimplify bits of a tree,
and then expect gimplify_expr() to gimplify the rest. This seems
redundant, as gimplify_expr() more often than not will gimplify the
ent
Hi folks.
I have merged mainline (rev 129233) into the tuples branch.
All compile.exp tests succeed. No regressions. Nothing of interest.
Aldy
101 - 200 of 252 matches
Mail list logo
