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
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
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
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
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
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
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
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
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
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
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
No anomalies. No regressions.
I will now post the full patchset I would like to post to trunk.
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
* 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
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
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
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.
* Bug 51752 - trans-mem: publication safety violated
I'm working on this.
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
> > ? ? ?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
> 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
> 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
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
> 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
> 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
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
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
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
> 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
> > ? ? 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
> > > 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
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 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 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,
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
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
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 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
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 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
> 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
> 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
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
> 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
> ../../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
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
> > ... 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
Hi folks.
Sorry I've taken so long on this. There was this marriage thing in
which I was a protagonist, and it's gotten me way off balance :).
I've been chasing my tail on implementation details. I was hoping
someone could give me a few hints.
>> A solution that comes to mind is to have the f
> You could combine the two ideas: a global hash table of types used in
> casts, where each entry had a list of functions using those types. That
> should take up no more storage than the per-function vectors. Then,
> you'd have to walk the entire hash table, writing out each type for
> which at
On Tue, Feb 14, 2006 at 06:08:42PM -0800, Mark Mitchell wrote:
> Aldy Hernandez wrote:
>
> > Do we keep a hash of functions that have been written out somewhere?
>
> Not to my knowledge.
>
> > I'd hate to walk the entire hash table each time we write out a func
Hi folks.
While investigating a regression from the V_MUST_DEF removal on mem-ssa,
I've noticed that we were missing out on optimization of certain
stores to complex types (on mainline).
For example, here:
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
we end up with:
# t_2 = V_MU
> I should also mention on the mainline, we get the decomposing for the
> orginal testcase which means this is a bug only on the MEM-SSA branch.
No we don't. Look at the actual testcase I posted. This is a bug on
mainline.
> Well, it's written to only in this testcase. Can you post a more complete
> one?
Here's the complete testcase.
int g(_Complex int*);
int f(void)
{
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
return g(&t);
}
> losing a slight missed optimization on the tree level.
Yay, exactly what I'm trying to fix. Glad you agree.
Aldy
Hi folks.
Under Diego's loving whip, I've been taking a look at GIMPLE tuples, and
have come up with a possible layout for the data structures representing
the tuples. It's a mix between what Mark and Diego's originally suggested
along with a few other things ;-).
Still missing are labels and gi
Hi folks!
You might have thought I've been drinking pi~na coladas in the sun, but
alas, I've been beating my head mercilessly with this gimple tuple business.
What I have so far is getting so big (280k), it's getting hard to manage and
keep track of things in my brain. What do you guys think abo
> I think this patch may have fried your brain slightly:
>
> (get_modify_stmt_operands): Rename from get_modify_stmt_operands.
Definitely! Good catch. Fixed.
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
> Please add your project page to the bottom of:
>http://gcc.gnu.org/wiki/GCC_4.3_Release_Planning
I just added a page for the tuples work.
Aldy
the
+ current notion of treating everything as a tree
+ (http://gcc.gnu.org/wiki/tuples";>
+ http://gcc.gnu.org/wiki/tuples).
+ This branch is maintained by Aldy Hernandez and will be routinely merged
+ with mainline. Patches and discussion on this branch should be marked with
+ the
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-
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.
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_
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 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
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
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
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
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.
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
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 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
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
=
> "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
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
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
Nothing interesting except less regressions. Yay.
> 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
> 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
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.
&
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#'
> 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
> 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
> 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
> 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-
> * 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
Hi Dan. Hi folks.
People (ok, so it was Dan) had asked if there was anything they could do to
help the tuples effort.
The pretty print routines could definitely use a lot of cases
(dump_gimple_stmt), and the work is very self contained.
There is also the constructors and accessors for the IR.
> >The pretty print routines could definitely use a lot of cases
> >(dump_gimple_stmt), and the work is very self contained.
>
> So I took a look at this the other day, and you seem to have at least
> every case that has accessors.
>
> Did you want me to write accessors for the other types and th
...as of rev 125166.
No surprises.
Aldy
On Wed, Jun 27, 2007 at 11:09:26AM -0400, Diego Novillo wrote:
> On 6/26/07 4:08 PM, Diego Novillo wrote:
>
> > But, first, I'd like to know what folks think about this. Would it be
> > generally useful for us to have the IL data structures auto-generated
> > this way? I can see the benefits in
> I have often been confused with the 'GS' prefix we have throughout the
> API. It's confusing as we seem to have two different things (GS and
> GIMPLE).
>
> I would like to propose that we rename all the 'gs' and 'GS' prefixes to
> 'GIMPLE'. That would mean renaming files, data structures and v
Hi Jan.
What do you expect DECL_SAVED_TREE to have in cgraph_analyze_functions:
/* ??? It is possible to create extern inline function and later using
weak alias attribute to kill its body. See
gcc.c-torture/compile/2009-1.c */
if (!DECL_SAVED_TREE (decl))
> The test there is sort of hack, I would just remove it at this stage and
> we can work out better fix for that testcase later. I hope that with my
> plans for declaration merging pass we can get round such weird side
> effects of in place declaration replacement.
Will do.
How about all the oth
> "Diego" == Diego Novillo <[EMAIL PROTECTED]> writes:
> are gimplify.c for all the conversion to GIMPLE, tree-cfg.c for the
> building of the CFG and omp-low.c for the conversion into Low
> GIMPLE.
Actually, gimple-low.c. omp-low.c is only for the OpenMP lowering.
I've been solving conflicts left and right and ran into the same set
of problems Diego describes independently.
What's up with cbsi_last()/bsi_last(), and the rest of the functions
that have been duplicated? We really shouldn't be changing APIs here,
and if we absolutely need more than one routin
Hi folks.
I have merged mainline (rev 129233) into the tuples branch.
All compile.exp tests succeed. No regressions. Nothing of interest.
Aldy
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
> 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
Pushed attached patch.
Thanks.
Aldy
On Tue, Sep 24, 2024 at 10:09 AM Filip Kastl wrote:
> On Mon 2024-09-23 09:43:28, Aldy Hernandez wrote:
> > From: Aldy Hernandez
> >
> > ChangeLog:
> >
> > * MAINTAINERS: Update email and add myself to
Below is a documented we have drafted to provide guidance on using
irange's and converting passes to it. This will future proof any such
passes so that they will work with the ranger, or any other mechanism
using multiple sub-ranges (as opposed to the more limited value_range).
The official d
On 9/9/20 7:03 PM, Martin Sebor wrote:
On 9/3/20 1:14 AM, Aldy Hernandez via Gcc wrote:
Below is a documented we have drafted to provide guidance on using
irange's and converting passes to it. This will future proof any such
passes so that they will work with the ranger, or any
101 - 200 of 252 matches
Mail list logo
