Hi folks.
Now that the branch is bootstrapping with no regressions (C and C++ anyhow),
I have run some memory benchmarks to make sure we're on the right path.
So far I have only implemented GIMPLE_MODIFY_STMT which is the tuples
counterpart of MODIFY_EXPR.
To compare memory usage, I forced a gar
> My vote is to merge into mainline sooner rather than later. However, it
> is a big patch and affects just about every module in the compiler, so I
> wouldn't want to barge in without getting some consensus first.
I agree with you and Mark.
What I'd like to do next is:
1. Merge mainline into
> Does the tuples branch include the CALL_EXPR reworking from the LTO branch?
No.
I have finished a merge from mainline @ 119445 into the tuples branch. It
bootstraps and exhibits only one regression in libjava:
FAIL: PR27908 -O3 execution - source compiled test
This has been around forever, I've just been lazy and hadn't figured out
how to run java tests individually. Tom T
Hi folks.
I have just merged gimple-tuples-branch into mainline.
The memory improvements as of last night are as follows:
-O0: 0.260409%
-O1: 0.828741%
-O2: 0.826724%
These are averages in analyzing about 8000 functions taken from Diego's .i
sandbox. I used the same met
> "DJ" == DJ Delorie <[EMAIL PROTECTED]> writes:
>> Oh, I get it now. No, there is no reason for the duplication between
>> minmax_operator and the insn itself. You should be able to remove the
>> tests from minmax_operator. I wonder why they are there at all?
> This, then?
Ok.
Hi guys!
I've been having sporadic conversations with both Diego and Rth regarding
tuples, and I wanted to sum up, and get others' opinions.
After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
to continue overloading trees will be more work in the long run than doing the
actu
> There are a lot of us that are happy to devote time and people
> resources to helping you with this (both design and implementation),
> so if you feel like you don't have time to go look at other IR's or
> something, please let us help :)
That would be great, especially the bit about looking at
ree, tree *);
Index: gsstruct.def
=======
--- gsstruct.def(revision 0)
+++ gsstruct.def(revision 0)
@@ -0,0 +1,55 @@
+/* This file contains the definitions for the gimple IR structure
+ enumeration used in GCC.
+
+ Copy
> > +/* A sequences of gimple statements. */
> > +#define GS_SEQP_FIRST(S) (S)->first
> > +#define GS_SEQP_LAST(S)(S)->last
> > +#define GS_SEQ_FIRST(S)(S).first
> > +#define GS_SEQ_LAST(S) (S).last
>
> Why do you have both of these?
Most places in the gimpl
ild/gencheck.o): Add gs.def.
Index: gimple-ir.c
===
--- gimple-ir.c (revision 0)
+++ gimple-ir.c (revision 0)
@@ -0,0 +1,154 @@
+/* Gimple IR support functions.
+
+ Copyright 2007 Free Software Foundation, Inc.
+ Contributed by Al
I have uploaded a new version of the tuples document, with the latest
discussions.
http://gcc.gnu.org/wiki/tuples
Aldy
Someone pointed out lack of documentation for the e500 cpu. Committing
to mainline, 4.0, 3.4, and 3.4-e500-branch.
Phew.
Aldy
* doc/invoke.texi: Add 8540 to list of cpus in rs6000 cpu section.
Index: doc/invoke.texi
===
RCS
Hi Richard.
I've been converting the ppc options to use the .opt machinery, and
am confused as to how to approach subtargets.
What's the deal with these?
I need options only for certain subtargets. For example, aix.h has
some options that should not be available by other targets.
I don't see a
> A back end for a target architecture in GCC has the following parts:
> [...]
> @item
> An optional @[EMAIL PROTECTED] file in the @[EMAIL PROTECTED]
> directory, containing a list of target-specific options. You can also
> add other option files using the @code{extra_opti
Hi folks.
All mail addressed to me from Apr-3 to Apr-10 was not delivered. I was
having problems with my mail setup. Please resend.
My apologies for reporting this so late; I've been sequestered at
customer sites with no internet for the past week after my vacation :-(.
Cheers.
Aldy
On Tue, May 10, 2005 at 06:54:12PM +0100, Joern RENNECKE wrote:
> Between 20050505 and 20050510, the ppc-eabisim configuration was broken.
> I'm seeing this error:
I'll take a look.
Aldy
> Some experimentation shows that the assembler from the two dates behaves
> the same,
> and eabi.S is identical, but the preprocessed source files differ. cc1
> used to define
> _RELOCATABLE, but it does not any more.
The problem is that target_flags_explicit was not being set on the
options t
Joern.
My combined tree is acting up, so I haven't tested a full build of
ppc-eabi*, but this fixes the -mlittle problem.
Let me know how it goes.
Aldy
* config/rs6000/sysv4.opt (mlittle): Handle.
* config/rs6000/rs6000.c (rs6000_handle_option): Set
target_flags_explici
On Wed, May 11, 2005 at 07:44:46PM -0400, Aldy Hernandez wrote:
> Joern.
>
> My combined tree is acting up, so I haven't tested a full build of
> ppc-eabi*, but this fixes the -mlittle problem.
>
> Let me know how it goes.
This patch fixed Joern's problems (well, t
Hi folks.
The code below is ICE-ing in C++:
typedef struct {
unsigned char dir;
int data[];
} AiDefaultRailBlock;
static const AiDefaultRailBlock _raildata_ai_0 = { 1, { 0, 4 } };
According to our docs, this is valid under flexible arrays:
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/Zero-L
More questions wrt this PR.
The problem here is in reshape_init_array_1. Ever since we made
max_index_cst and index *unsigned* HOST_WIDE_INT, we are causing the
loop over initializers to wrongly iterate when we have zero sized arrays.
Since on a zero sized array, we have "tree max_index" set to:
Hi folks.
In this PR we are emitting a "value computed is not used" warning for the
following code (via some fancy macro expansion in the Linux kernel):
unsigned long t(void);
void apic_write_atomic(unsigned long reg, unsigned int v)
{
((__typeof__(*((volatile un
On a similar note than PR debug/21391...
In PR23336 we have the same thing happen with enums:
enum something { JTI_PROMOTED_BYTE_TYPE_NODE, etc };
use JTI_PROMOTED_BYTE_TYPE_NODE
JTI_PROMOTED_BYTE_TYPE_NODE and "something" get pruned even though we
use it. I see two alternative
> A stronger case for changing this would be that gcc version
> n-1 didn't warn. As discussed elsewhere, some modicum of
> stability in warnings is desirable from the user's perspective.
> I don't know whether or not this applies in this case.
Well, as I mentioned in the PR, macro writers can wra
On Thu, Nov 17, 2005 at 10:24:21PM -0800, Mark Mitchell wrote:
> Richard Henderson wrote:
>
> > A solution that comes to mind is to have the front-end add dummy
> > TYPE_DECL nodes to the BLOCK_VARS list of the function's outer-most
> > BLOCK. If the TYPE_DECL node were marked DECL_ARTIFICIAL and
> "Richard" == Richard Henderson <[EMAIL PROTECTED]> writes:
> On Tue, Nov 29, 2005 at 12:42:36PM -0800, Mark Mitchell wrote:
>> RTH is listed as the author of a lot of those bits, so perhaps he knows
>> more?
> The glibc bits handle ieee quad format, whereas I don't believe
> that Torba
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Henderson wrote:
>> The glibc bits handle ieee quad format, whereas I don't believe
>> that Torbajorn's does. I don't recall if Torbajorn's code allows
>> for emulation of all rounding modes or exception bits.
> I believe i
BTW, here is the original thread I had started:
http://gcc.gnu.org/ml/gcc/2003-04/msg00695.html
> > There was a thread discussing all this, when I was interested in doing
> > the work. I mailed rms directly, and he said it was ok to use the
> > glibc bits in gcc regardless of the LGPL/GPL dispar
On Thu, Dec 01, 2005 at 04:18:20PM +0100, Steven Bosscher wrote:
> Hi Aldy,
>
> The MS1 backend is not listed in http://gcc.gnu.org/backends.html.
> Could you please add it?
This is what I have.
Nathan, how does this look to you?
Index: backends.html
> I think the line should be
> + ms1 | S F B p g bd
Argh, I misread "does not" for "does".
Ok, committing the following.
Index: backends.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/backends.html,v
retrieving revision
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
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
-
On 06/06/2015 09:20 AM, Andreas Schwab wrote:
Aldy Hernandez writes:
Does the 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
On 06/06/2015 03:33 PM, Jan Hubicka wrote:
Aldy,
also at PPC64le LTO bootstrap (at gcc112) dies with:
^
0x104ae8f7 check_die
../../gcc/dwarf2out.c:5715
Hmmm... this is in the LTO/ltrans stage? If so, that's weird. The LTO
path does not do the early DIE dance. Since check_die() is a
On 06/06/2015 05:47 PM, Aldy Hernandez wrote:
On 06/06/2015 03:33 PM, Jan Hubicka wrote:
Aldy,
also at PPC64le LTO bootstrap (at gcc112) dies with:
^
0x104ae8f7 check_die
../../gcc/dwarf2out.c:5715
Hmmm... this is in the LTO/ltrans stage? If so, that's weird. The LTO
path doe
On 06/07/2015 07:28 AM, Ramana Radhakrishnan wrote:
On Sat, Jun 6, 2015 at 10:49 AM, Andreas Schwab wrote:
Bootstrap fails on aarch64:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc
422e1355
Author: Aldy Hernandez
Date: Sun Jun 7 07:32:12 2015 -0400
* objc-runtime-shared-support.c (build_module_descriptor): Set
TREE_USED on UOBJC_MODULES_decl.
diff --git a/gcc/objc/objc-runtime-shared-support.c
b/gcc/objc/objc-runtime-shared-support.c
index d9b3c27..1bcb14a 1
On 06/06/2015 05:49 AM, Andreas Schwab wrote:
Bootstrap fails on aarch64:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1-checksum.o differs
Bootstrap comparison failure!
gcc/ira-c
On 06/07/2015 11:25 AM, Richard Biener wrote:
On June 7, 2015 5:03:30 PM GMT+02:00, Aldy Hernandez wrote:
On 06/06/2015 05:49 AM, Andreas Schwab wrote:
Bootstrap fails on aarch64:
Comparing stages 2 and 3
warning: gcc/cc1objplus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
On 06/08/2015 04:03 AM, Iain Sandoe wrote:
Hi Aldy,
On 7 Jun 2015, at 12:37, Aldy Hernandez wrote:
On 06/07/2015 06:19 AM, Andreas Schwab wrote:
Another fallout:
FAIL: obj-c++.dg/try-catch-5.mm -fgnu-runtime (test for excess errors)
Excess errors:
: warning: '_OBJC_Module' defin
"Eric S. Raymond" writes:
> The remaining list is pretty short:
>
> bson = bson
I worked on a project together with a Jan Brittenson a very long time
ago. He worked on GNU finger, and some bytecode representation for GCC
way back when... for the FSF.
Actually he was very instrumental in getti
Howdy!
I'm working on enhancements to our out-of-bounds warnings in VRP, such
that we can warn and isolate conditionally out-of-bound accesses
(similar to what we do in gimple-ssa-isolate-paths.c for NULL accesses).
With my WIP I have found the following out of bounds in the array access
at
On 03/23/2016 10:25 AM, Bernd Schmidt wrote:
On 03/23/2016 07:32 AM, Aldy Hernandez wrote:
int
maximal_insn_latency (rtx insn)
{
int insn_code;
if (insn == 0)
insn_code = DFA__ADVANCE_CYCLE;
else
{
insn_code = dfa_insn_code (as_a (insn));
if (insn_code
On 03/24/2016 10:02 AM, Alexander Monakov wrote:
Hi,
On Thu, 24 Mar 2016, Bernd Schmidt wrote:
On 03/24/2016 11:17 AM, Aldy Hernandez wrote:
On 03/23/2016 10:25 AM, Bernd Schmidt wrote:
It looks like this block of code is written by a helper function that is
really intended for other
Hi guys!
I'm looking at libiberty's use of alloca() and trying to place some
bounded checks at alloca() call points.
Silly question, do we have any users of regex.c with REGEX_MALLOC set?
I don't see any #define for REGEX_MALLOC anywhere in binutils or gcc,
and it doesn't look like autoconf
On 07/23/2016 06:33 AM, Aldy Hernandez wrote:
If the REGEX_MALLOC mode in regex.c is unused, can I rip it out? I'd
like to replace it all with alloca with a malloc fallback.
And yes, I realize regex.c already does this most of the time:
if (size1 > MAX_ALL
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could prove painful after 15 years of
divergence.
The current gl
On 07/29/2016 07:30 AM, Aldy Hernandez wrote:
On 07/25/2016 06:30 PM, Manuel López-Ibáñez wrote:
On 25/07/16 21:16, Joseph Myers wrote:
On Mon, 25 Jul 2016, Jeff Law wrote:
I'll pre-approve removing those bits. Alternately, you could look to
resync
with glibc, though that could
Jeff Law writes:
>> We don't need to change the final approval step being from a
>> maintainer to be able to spread the workload.
> Amen. There's a few folks doing this right now outside their areas of
> official maintainership and those comments are always very helpful to
> me.
>
> And note tha
Hi folks. I'm working on better range information with Macleod, and
I've been playing with folding arbitrary range expressions, which I
expect fold() to ahem...fold.
I'm surprised that even seemingly simple trees can't be folded after
they've been built, because AFAICT, fold actually just wor
On 09/14/2016 09:32 AM, Jakub Jelinek wrote:
On Wed, Sep 14, 2016 at 09:25:30AM -0400, Aldy Hernandez wrote:
Hi folks. I'm working on better range information with Macleod, and I've
been playing with folding arbitrary range expressions, which I expect fold()
to ahem...fold.
I'm
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
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
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
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 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
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/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
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
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
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!
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
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
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
Howdy!
Are the types for PHI arguments and the corresponding result supposed to
match?
In the backwards threader I'm seeing:
_103 = PHI <_173(11), 0B(12)>
Where the type of _103 is cgraph_node *, and the type of _173 is
symtab_node *.
I know one is derived from the other (struct c
On 10/19/18 1:00 PM, Jakub Jelinek wrote:
On Fri, Oct 19, 2018 at 12:47:00PM -0400, Aldy Hernandez wrote:
Howdy!
Are the types for PHI arguments and the corresponding result supposed to
match?
Like with most other gimple stmts, they need to satisfy
useless_type_conversion_p (TREE_TYPE
Hi Ian. Hi folks.
I have some libgo failures which I'm pretty sure I caused (see below for
details), but I can't seem to figure out how to reproduce. Before I go
down the rabbit hole, is there an easy way of reproducing say:
FAIL: database/sql
FAIL: net/http
I'm used to scouring
x86_64-pc
On 3/12/19 3:28 PM, Ian Lance Taylor wrote:
On Tue, Mar 12, 2019 at 11:20 AM Aldy Hernandez wrote:
I have some libgo failures which I'm pretty sure I caused (see below for
details), but I can't seem to figure out how to reproduce. Before I go
down the rabbit hole, is there an e
On 5/28/19 10:40 AM, Jeff Law wrote:
On 5/23/19 7:10 AM, Richard Biener wrote:
On Thu, May 23, 2019 at 3:29 AM Andrew MacLeod wrote:
There is a functioning prototype in branch “ssa-range” which is a proof
of concept that the approach is functional as well as quick, and can be
used to answe
Short summary:
a) we'll unify value_range and the irange API, confirm there are no new
bugs nor performance issue. This would considered complete when the
ranger is able to fully run using value_range instead of irange.
[snip]
Does this seem reasonable?
I think that's a reasonable pla
Jeff Law writes:
>> If you build sth as part of GCC then why is it a plugin in the first place?
> I think we want plugins for domain-specific analysis. Having a
> repository for well developed checkers makes sense to me, particularly
> for checkers which are useful across projects.
>
> One such
Hi folks.
I've been having troubles comparing the results of different test runs
for quite some time, and have finally decided to whine about it.
Perhaps someone can point out to whatever I may be doing wrong.
I generally do "make check -k -j60" on two different trees and compare
the results
Jason Merrill writes:
> Yes, the git mirror can lag the SVN repo by a few minutes, that's why
> you need to 'git svn rebase' to pull directly from SVN before a
> commit.
>
> Jason
Markus just said upthread that:
"git svn dcommit" will run "git svn rebase" automatically
Is `git svn rebase' run
Hi folks.
Calling wi::max_value() of a boolean_type creates a wide_int with all
bits set, not just the least significant bit.
tree type = boolean_type_node;
wide_int x = wi::max_value (TYPE_PRECISION (type), TYPE_SIGN (type));
(gdb) print x.dump()
[0x], precision = 1
However,
you had in mind, or would you prefer the sign extension
in the wi::int_traits decompose routine?
Or somewhere else entirely ;-).
Thanks.
Aldy
On Sun, Aug 20, 2017 at 6:40 AM, Richard Biener
wrote:
> On August 20, 2017 10:46:54 AM GMT+02:00, Aldy Hernandez
> wrote:
>>Hi folks.
>
Hi!
I'm looking at tree-ssa-threadbackward.c, where we pass around a lot
of "vec" pointers representing a path through a
flow graph.
I'm wondering why we use va_gc, when AFAICT, the paths are local to
the pass, and we can easily free them with path.release() at the end
of the pass. For that matt
I understand the need for .quick_push(), when we know the size of the
allocated elements before hand, but do we really need to call the
common variant safe_push? Can't we just call it push()?
Or is there some magic C++ rule/idiom that prohibits us from doing this?
I volunteer to provide a patch
So ok to default to a lazy one, or are suggesting we leave things
as they are?
Aldy
On Thu, Aug 31, 2017 at 7:38 AM, Richard Biener
wrote:
> On Thu, Aug 31, 2017 at 1:31 PM, Aldy Hernandez wrote:
>> I understand the need for .quick_push(), when we know the size of the
>> all
On Wed, Aug 30, 2017 at 10:32 AM, Jeff Law wrote:
> On 08/30/2017 04:41 AM, Aldy Hernandez wrote:
> If you're looking for further cleanups, pulling the rest of the FSM bits
> out of tree-ssa-threadupdate.c is ripe. In particular this loop:
>
> /* Jump-thread all FSM threa
Howdy.
In the backwards threader we attempt to thread paths that lead to a
basic block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a
GIMPLE_GOTO. The latter doesn't make much sense, since we only handle
constants. What does a goto to a constant mean? Does that ever happen?
In tree-s
On 10/26/2017 08:31 AM, Richard Biener wrote:
On Thu, Oct 26, 2017 at 1:05 PM, Aldy Hernandez wrote:
Howdy.
In the backwards threader we attempt to thread paths that lead to a basic
block ending in either a GIMPLE_COND, GIMPLE_SWITCH, or a GIMPLE_GOTO. The
latter doesn't make much
On 05/30/2018 10:51 AM, Andreas Schwab wrote:
On Mai 30 2018, David Malcolm wrote:
On Tue, 2018-05-29 at 19:53 -0400, Andrew MacLeod wrote:
[...snip...]
The code is located on an svn branch *ssa-range*. It is based on
trunk
at revision *259405***circa mid April 2018.
Is this svn branc
Howdy.
I'm looking at the ABS_EXPR code in extract_range_from_unary_expr() and
have noticed that by the time we get here:
/* If a VR_ANTI_RANGEs contains zero, then we have
~[-INF, min(MIN, MAX)]. */
if (vr0.type == VR_ANTI_RANGE)
...we have already handled VR_VARYING, V
Howdy.
Am I missing something or are these two sets identical?
/* Get the lower and upper bounds of the type. */
if (TYPE_OVERFLOW_WRAPS (expr_type))
{
type_min = wi::min_value (prec, sgn);
type_max = wi::max_value (prec, sgn);
After 20 years of hacking on GCC I feel like I have literally wasted
days of my life typing out ChangeLog entries that could have easily been
generated programmatically.
Can someone refresh my memory here, what are the remaining arguments for
requiring ChangeLog entries?
I vaguely recall Jak
On 07/05/2018 04:07 AM, Richard Biener wrote:
On Thu, Jul 5, 2018 at 9:47 AM Aldy Hernandez wrote:
After 20 years of hacking on GCC I feel like I have literally wasted
days of my life typing out ChangeLog entries that could have easily been
generated programmatically.
Can someone refresh
Wait, there's a pot of money for making SVN go away? Sign me up!
While we're at it, let's start one for TCL and dejagnu!
On Mon, Jul 9, 2018 at 6:58 PM Jeff Law wrote:
>
> On 07/09/2018 10:53 AM, Janus Weil wrote:
> > 2018-07-09 18:35 GMT+02:00 Eric S. Raymond :
> >> David Edelsohn :
> The t
On Thu, Jul 12, 2018 at 1:41 PM Jonathan Wakely wrote:
>
> On Thu, 12 Jul 2018 at 11:41, Richard Sandiford wrote:
> > +Only use non-constant references in the following situations:
> > +
> > +
> > +
> > +when they are necessary to conform to a standard interface, such as
> > +the first argument to
On Thu, Jul 12, 2018 at 8:02 PM Pedro Alves wrote:
>
> On 07/12/2018 05:17 PM, Richard Sandiford wrote:
> > Pedro Alves writes:
>
> >> (an
> >>> alternative to pointers is to return a struct with the wide int result
> >>> and the overflow flag),
> >>
> >> +1. I've been pushing GDB in that direct
On 07/16/2018 04:19 AM, Richard Sandiford wrote:
Aldy Hernandez writes:
On Thu, Jul 12, 2018 at 1:41 PM Jonathan Wakely wrote:
On Thu, 12 Jul 2018 at 11:41, Richard Sandiford wrote:
+Only use non-constant references in the following situations:
+
+
+
+when they are necessary to conform
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
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
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/
> 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 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
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
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.
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.
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
1 - 100 of 252 matches
Mail list logo
