Hi,
[for certain test cases :-) ]
the temp slot cleanups I just sent where actually motivated by PR38474.
It exposes many slownesses in the compiler, but at -O0 the only remaining
one is the expand phase. expanding variables is the one thing (on my
machine here, with -O0 -g f951): 30
Hi,
On Fri, 25 May 2012, NightStrike wrote:
This point of yours should be stressed. Using writing standards of
one language to develop in another language is a fundamentally bad
idea. C and C++ kind of look the same, but they are not:
http://www.research.att.com/~bs/bs_faq.html#C-slash
Hi,
On Fri, 25 May 2012, Jakub Jelinek wrote:
+ /* Return the current size of this hash table. */
+
+ size_t size()
+ {
+return htab-size;
+ }
(and various other places) - formatting is wrong, missing space between (.
And it doesn't start at the first column, and type
Hi,
On Fri, 25 May 2012, Gabriel Dos Reis wrote:
(and various other places) - formatting is wrong, missing space
between (.
And it doesn't start at the first column, and type isn't on a separate
line. I realize that this is a member method, hence indenting and C
GNU coding
Hi,
On Fri, 25 May 2012, Steven Bosscher wrote:
Note also the almost 2 decades of C++ style practice in our libstdc++
implementation.
That's one of my fears, namely that those used to the libstdc++ style
impose that on the compiler source base. Because IMHO the libstdc++
style
Hi,
I've noticed that libitm is always rebuild with a non-bootstrap tree even
with merely a sequence of two makes. The reason turns out to be that
installation of unwind.h from libgcc, which is always done with a simple
make:
# make
# make -d
...
dest=../.././gcc/include/tmp$$-unwind.h; \
Hi,
On Fri, 25 May 2012, Diego Novillo wrote:
That's one of my fears, namely that those used to the libstdc++
style impose that on the compiler source base. Because IMHO the
libstdc++ style isn't very appealing.
Seconded.
I don't care how ugly coding conventions look.
Perhaps
Hi,
On Fri, 25 May 2012, Olivier Hainque wrote:
I've noticed that libitm is always rebuild with a non-bootstrap tree even
with merely a sequence of two makes. The reason turns out to be that
installation of unwind.h from libgcc, which is always done with a simple
make:
This should
Hi,
On Tue, 22 May 2012, Richard Guenther wrote:
I had thought of that as well. But it is not quite that simple -- the
problem is that tree-ssa-reassoc.c as part of its core algorithm
reassociates
expressions all the time while even still building up the tree, see e.g.
linearize_expr
Hi Eric,
there's a call to expand_decl in gcc-interface/utils.c, which is used only
for setting up some field of CONST_DECLs. I'm working on removing this
function, and removing that call from utils.c is seemingly working just
fine. It came in with :
2005-11-14 Thomas Quinot
Hi,
On Mon, 21 May 2012, Richard Guenther wrote:
This removes the code that makes us walk DECL_INITIAL (recursively)
on add_referenced_var - one source of compile-time hogs in the past
and not strictly necessary.
For this to be a compile time hog, ...
if (referenced_var_check_and_insert
Hi,
On Mon, 14 May 2012, H.J. Lu wrote:
As a minor nitpick, I have always used x32 with a lower case x. The
capital X32 looks odd to me.
I used X32 together with LP64. I can use ILP32 instead of X32 when LP64
is mentioned at the same time.
I'd prefer that. x32 is a nice
Hi,
On Fri, 11 May 2012, Basile Starynkevitch wrote:
However, the type gimple_seq still appears in a lot of source files
(mostly gcc/gimple*.c gcc/tree*.c)
Is this intended, or is this a temporary situation, and
further patches would remove all occurrences of gimple_seq everywhere?
I'm
Hi,
the current code for strided loads can't deal with the situation when a
prologue loop (peeling for alignment) is created after analyzing the data
refs. There are multiple issues (non-constant steps in DRs mainly), so
this is a simple stop gap.
Regtesting on x86_64-linux (all langs) in
Hi,
On Mon, 7 May 2012, Mike Stump wrote:
On May 7, 2012, at 6:11 AM, Michael Matz wrote:
I'd like to retain the #if 0 code therein,
Can you structure this code as
#define DEBUG 0
if (DEBUG) ...
?
If so, that would be a preferable way to structure the code.
Sure, consider
in (r187288). Only change from
submission is the intro of BB_HEADER/BB_FOOTER macros.
Ciao,
Michael.
---
2012-05-03 Michael Matz m...@suse.de
* basic-block.h (struct rtl_bb_info): Remove visited member and
move head_ member to ...
(struct
Hi,
neverending story. Maybe this time something gets in :)
This patch changes generation of insn-attrtab.c to:
* order attributes topologically (so that the inlining genattrtab does
is as effective as possible, and doesn't hit the size limits too much)
* adjusts the rtx_cost for the
that
Richi asked me for.
Regstrapped on x86_64-linux, all langs, no regressions. Okay for trunk?
Ciao,
Michael.
2012-05-02 Michael Matz m...@suse.de
* basic-block.h (struct rtl_bb_info, struct gimple_bb_info): Move
in front of basic_block_def.
(struct
would accept anonymous structs for our sources, but we don't.
Currently regstrapping on x86_64-linux, okay if that passes?
Ciao,
Michael.
-
2012-05-03 Michael Matz m...@suse.de
* basic-block.h (struct rtl_bb_info): Remove visited member and
move head_
Hi,
On Wed, 2 May 2012, Richard Guenther wrote:
Please remove the flags.
Okay.
can you factor out this idiom to sth like gsi_new_seq_from_stmt () or so?
Or gimple_init_seq_pointers? Not necessarily exported.
gimple_init_singleton it is. The whole series is now at r187053.
Ciao,
Hi,
my gimple_seq reshuffling broke boostrap on some machines. In particular
on those for which contrib/compare-debug works, meaning that
bootstrap-debug is selected as default BUILD_CONFIG (none of my machines
pass the respective configure.ac test, and hence I wasn't seeing the
problem
Hi,
a long time ago, during development of [tuples] gimple_statement_base had
prev/next links. Those were moved to gimple_seq_node, referred to from
gimple_seq, and referring to gimple statements, on the grounds that this
eases experimentation with different data structures. Well, those
exception is when the seq will be used in an iterator).
As per [0/6] regstrapped together with the other five patches on
x86_64-linux. Okay for trunk?
Ciao,
Michael.
2012-05-02 Michael Matz m...@suse.de
* tree-phinodes.c (add_phi_node_to_bb): Tidy, don't
to represent the data
structures and might not be strictly needed anymore, but I've always
tested with it, and it's definitely not harmful.
As per [0/6] regstrapped with the other five on x86_64-linux. Okay for
trunk?
Ciao,
Michael.
--
2012-05-02 Michael Matz m...@suse.de
-05-02 Michael Matz m...@suse.de
* gimple.h (gimple_seq_first, gimple_seq_first_stmt, gimple_seq_last,
gimple_seq_last_stmt, gimple_seq_set_last, gimple_seq_set_first,
gimple_seq_empty_p, gimple_seq_alloc_with_stmt, bb_seq,
set_bb_seq): Move down to after
, as should be the whole 1-5
sequence of patches. As per [0/6] regstrapped with the other five on
x86_64-linux. Okay for trunk?
Ciao,
Michael.
2012-05-02 Michael Matz m...@suse.de
* gimple.h (gimple_stmt_iterator seq): Make it be pointer to
gimple_seq
, straighten the
asserts and leave uid be a normal 32bit integer. Just tell me.
As per [0/6] regstrapped with the other five patches on x86_64-linux.
Okay for trunk (with or without the start/end_of_seq flags)?
Ciao,
Michael.
--
2012-05-02 Michael Matz m...@suse.de
Hi,
On Thu, 19 Apr 2012, Michael Matz wrote:
I've audited all other calls of va_end in the compiler and these were the
only problematic ones.
Well, I did, but forgot the fact that I found one in cp/error.c, so the
generated diff and the commit forgot that file too
Hi,
I observed this with an alternate implementation of the stdarg stuff that
allocs new va_lists for va_start and va_copy, and frees them on va_end.
Some routines of diagnostic.c called va_end while the va_list was still
stored away in the diag objects and used in report_diagnostic.
I've
Hi,
On Mon, 16 Apr 2012, Richard Guenther wrote:
This fixes PR52977 - for PCH to work with its pointer relocation code we
have to avoid dereferencing pointers to compute array lengths in
structures. So we have to unfortunately keep duplicated info about
VECTOR_CST vector lengths.
That's
Hi,
On Mon, 16 Apr 2012, H.J. Lu wrote:
Hi Michael,
Can you apply IFUNC spec to x86-64 psABI?
Yes, ...
BTW, where can I find the latest x86-64 psABI source? The svn
site:
https://www.x86-64.org/svn/trunk/x86-64-ABI
is down.
... once I find out what the problem with that is :)
Hi,
On Wed, 11 Apr 2012, Richard Guenther wrote:
But it would possibly be an interesting experiment already to do such
transformation generally (without profiling) and see what it gives on
some benchmarks. Just to get a feel what's on the plate.
The question is, of course, why on
Hi,
On Tue, 10 Apr 2012, Jakub Jelinek wrote:
*) gcc implementation has lots of hard coded TREE_OPERAND (exp, nn)
e.g.
exp-as_component_ref().get_field() ..
exp-as_mem_access().get_base() ...
exp-as_mem_acesss().get_address() -- produces
Hi,
On Tue, 10 Apr 2012, Gabriel Dos Reis wrote:
To be honest, all of those sound fine to me...
bike-sheddin',
-miles
at the risk of more bike sheds: -Wcommon ?
To use a variant of your own counterargument against -Wdefault: common
also has a special commonly (ahem :) used
Hi,
On Tue, 10 Apr 2012, Xinliang David Li wrote:
exp-as_component_ref().get_field() ..
Actually it's not questionable. The above stuff is _horrible_.
Specifics please. It is _horrible_ because you are more used to the
existing way and the new style does not match your
Hi,
and this implements generally strided loads where the stride is a
loop-invariant (constant or ssa-name). We only do so if the load can't be
handled by interleaving groups. The implementation is fairly straight
forward:
for (i = 0; i n; i += stride)
... = array[i];
Hi,
this patch speeds up polyhedrons protein on Bulldozer quite a bit. The
things is that in this testcase cshift is called with a very short length
(=3) and that the shift amount always is less than the length.
Surprisingly the division instruction takes up considerable amount of
time, so
Hi,
On Tue, 10 Apr 2012, Steven Bosscher wrote:
This is OK.
r186283.
Do you think it would be worthwhile to do this transformation in the
middle end too, based on profile information for values?
I'd think so, but it probably requires a new profiler that counts for how
often 0 = A = B for
Hi,
On Tue, 10 Apr 2012, Richard Guenther wrote:
+ vec_inv = build_constructor (vectype, v);
+ new_temp = vect_init_vector (stmt, vec_inv, vectype, gsi);
+ new_stmt = SSA_NAME_DEF_STMT (new_temp);
+ mark_symbols_for_renaming (new_stmt);
This should not
Hi,
On Fri, 30 Mar 2012, Jan Hubicka wrote:
Motion across hardreg sets/uses are not restricted. And I would not expect
an optimizing compiler to do that (it's your own fault to use hardregs in
complex C code).
Well, the syscall sequence is an example of somehting that should be
Hi,
On Fri, 30 Mar 2012, Gabriel Dos Reis wrote:
On Fri, Mar 30, 2012 at 7:45 PM, David Malcolm dmalc...@redhat.com wrote:
Here's another proposal then: actually use GObject introspection -
provide a GObject-based API to GCC.
In this approach, GCC would gain a dependency on glib and
Hi,
On Mon, 2 Apr 2012, Jakub Jelinek wrote:
inline int syscall1(int number, long arg1) {
register int ax __asm__(eax);
register long di __asm__(rdi);
ax = number;
di = arg1;
__asm__ volatile (syscall);
}
_then_ we would probably get miscompilations here and there.
Hi,
On Thu, 29 Mar 2012, Sriraman Tallam wrote:
+struct __processor_model
+{
+ /* Vendor. */
+ unsigned int __cpu_is_amd : 1;
+ unsigned int __cpu_is_intel : 1;
+ /* CPU type. */
+ unsigned int __cpu_is_intel_atom : 1;
+ unsigned int __cpu_is_intel_core2 : 1;
+ unsigned int
Hi,
So here's an extended variant of my hack that implements throwing asms.
Like rth proposed I've added a new pseudo clobber, throw:
int f (void)
{
int x, y;
x = 1;
y = 2;
try {
__asm__ ( : =r(x), =r(y) : : throw);
} catch (...) {
return 2+x+y;
}
return x+y;
}
The patch
Hi,
On Thu, 29 Mar 2012, Stephan Bergmann wrote:
Anyway, would it be worthwhile filing an RFE for an asm annotation
telling the compiler that it contains code that can throw?
I suppose yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52770 RFE: Letting
compiler know asm block can
Hi,
On Thu, 29 Mar 2012, Andrew Haley wrote:
On 03/29/2012 02:59 PM, Michael Matz wrote:
Actually, with -fnon-call-exceptions volatile asms are already supposed to
be throwing. It's just that this got lost with tree-ssa. With the patch
and -fnon-call-exceptions a simple __asm__
Hi,
On Wed, 21 Mar 2012, Mike Stump wrote:
If the high bit of i1 is set then currently you will get a negative
number produced no matter the absolute value of it.
Ok, in the new patch, I'm pushing to change the spec so that the value
is sign extended and fixing all the code that
Hi,
On Wed, 21 Mar 2012, Mike Stump wrote:
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -531,10 +531,9 @@ immed_double_const (HOST_WIDE_INT i0, HOST_WIDE_INT i1,
enum machine_mode mode)
1) If GET_MODE_BITSIZE (mode) = HOST_BITS_PER_WIDE_INT, then we use
gen_int_mode.
-
Hi,
On Tue, 20 Mar 2012, Mike Stump wrote:
Actually you did. I've tried yesterday to come up with a text that
would do the same (because I agree with you that deleting the assert
changes the spec of the function,
The spec of the function is the text above the definition of the
Hi,
On Tue, 20 Mar 2012, Richard Sandiford wrote:
If Mike or anyone is up to doing that, then great. But if instead it's
just a case of handling zero correctly, moving rather than removing the
assert seems safer.
I'm obviously not explaining this well :-)
Actually you did. I've tried
Hi,
On Thu, 15 Mar 2012, Richard Guenther wrote:
The type demotion is PR45397/PR47477 among other PRs. I'd just walk
from the narrowing integer conversion stmts recursively through the
def stmts, see if they can be narrowed, note it, and finally if
everything or significant portion of
Hi,
On Mon, 12 Mar 2012, Martin Jambor wrote:
OK, the following patch changes the places where I previously called the
new function to call expand_expr with EXPAND_WRITE modifier and then
makes sure we do not perform reads into rvalues in expand_expr_real_1 in
the contexts where I need to
Hi,
On Mon, 12 Mar 2012, Martin Jambor wrote:
when we expand a misaligned MEM_REF on the LHS, we must not call the
code in expand_expr_real_1 if the subsequent patch is applied, because
the code generates code extracting the contents of the memory to a
register, which is of course bad if the
Hi,
On Wed, 7 Mar 2012, Richard Guenther wrote:
FAIL: gcc.dg/tree-ssa/pr31261.c scan-tree-dump-times original return
\\(char\\)
-\\(unsigned char\\) c 31; 1
FAIL: gcc.dg/tree-ssa/pr31261.c scan-tree-dump-times original return
\\(int\\)
\\(12 - \\(unsigned int\\) d\\) 7; 1
because
Hi,
On Mon, 5 Mar 2012, Arnaldo wrote:
I couldn't get cfgexpand.c:basic_block expand_gimple_basic_block
(basic_block bb) to work by calling it directly because there is some
preprocessing in gimple_expand_cfg() that has to be done first. But
calling gimple_expand_cfg() modifies the CFG
Hi,
On Wed, 29 Feb 2012, Richard Guenther wrote:
the whole base object - instead I mark the base MEM_REF of such accesses
with TREE_NO_WARNING (ugh) and special-case for them in dr_may_alias_p.
At least use a flag that isn't currently used for MEM_REF. E.g.
addressable_flag, and make a
Hi,
On Mon, 27 Feb 2012, Aldy Hernandez wrote:
For that matter, didn't rth add a memory barrier at the beginning of
transactions last week? That would mean that we can't hoist anything
outside of a transaction anyhow. Or was it not a full memory barrier?
It's now a full memory
Hi,
On Thu, 9 Feb 2012, Andrew Haley wrote:
On 02/09/2012 03:28 PM, Richard Guenther wrote:
So - do you have an idea what routines we can start off with to get
a full C99 set of routines for float, double and long double? The last
time I was exploring the idea again I was looking at the
Hi,
On Thu, 9 Feb 2012, James Courtier-Dutton wrote:
Results when compiled for 32bit x86.
gcc -m32 -g -O0 -c -o sincos1.o sincos1.c
gcc -m32 -static -g -o sincos1 sincos1.o -lm
./sincos1
sin = 4.62613040764601746e-01
sinl = 0.46261304076460176
sincos = 4.62613040764601746e-01
sincosl =
Hi,
On Thu, 9 Feb 2012, Andrew Haley wrote:
So - do you have an idea what routines we can start off with to get
a full C99 set of routines for float, double and long double? The
last time I was exploring the idea again I was looking at the BSD
libm.
I'd start with INRIA's crlibm.
Hi,
On Fri, 3 Feb 2012, Vincent Lefevre wrote:
No normal math library supports such an extreme range, even basic
identities (like cos^2+sin^2=1) aren't retained with such inputs.
I agree: the program is complete nonsense.
I disagree: there may be cases where large inputs can be
Hi,
On Fri, 3 Feb 2012, Vincent Lefevre wrote:
For the glibc, I've finally reported a bug here:
http://sourceware.org/bugzilla/show_bug.cgi?id=13658
That is about 1.0e22, not the obscene 4.47460300787e+182 of the
original poster.
But 1.0e22 cannot be handled correctly.
On Fri, 3 Feb 2012, Dominique Dhumieres wrote:
Note that sqrt(2.0)*sin(4.47460300787e+182+pi/4) gives a diffeent value
for the sum.
In double: 4.47460300787e+182 + pi/4 == 4.47460300787e+182
Ciao,
Michael.
Hi,
On Wed, 1 Feb 2012, Linus Torvalds wrote:
But I also think that gcc is simply *buggy*, and has made them much
nastier than they should be. What gcc *should* have done is to turn
bitfield accesses into shift-and-masking of the underlying field as
early as possible, and then do all
Hi,
On Thu, 2 Feb 2012, Aldy Hernandez wrote:
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.
Sure.
Hi,
On Wed, 1 Feb 2012, Jiri Kosina wrote:
# cat x.c
struct x {
long a;
volatile unsigned int lock;
unsigned int full:1;
};
void
wrong(struct x *ptr)
{
ptr-full = 1;
}
In my opinion, this is a clear bug
Even that depends (sadly) on who you ask. half-volatile
Hi,
On Fri, 27 Jan 2012, William J. Schmidt wrote:
int
test_switch_1 (unsigned int *index, int i)
{
switch (*index)
...
However, for the first case, temporary expression replacement has
effectively removed the
Hi,
On Fri, 27 Jan 2012, Rainer Orth wrote:
Paolo Carlini paolo.carl...@oracle.com writes:
On 01/27/2012 05:27 PM, Rainer Orth wrote:
They would be exported @3.4.11 if they had been present before. On
Solaris before 4.7, there were not. Rainer
Ah, Ok, now I see, you are talking about
Hi,
On Thu, 26 Jan 2012, Richard Henderson wrote:
On 01/26/2012 03:04 AM, Michael Matz wrote:
Actually, resx/eh_dispatch always are the last BB statements, so the loop
doesn't need to look at all statements in a BB, making it quite somewhat
faster. Consider the tree-eh.c to be looking
Hi,
On Tue, 24 Jan 2012, Richard Guenther wrote:
+ !is_gimple_reg (t))
+
Ok with the excessive vertical space removed.
Actually the patch as is was regressing some testcases (pr48794.f90, fixed
with an tree-eh change in another thread) and pack9.adb, which is fixed
with the
Hi,
so, the below adjusted testcase from PR48794 still fails for the same
reasons (regions still referenced from RESX being removed). I was split
minds about if that's a new bug or just an extension of the old bug, so I
hijacked the old PR. In any case, remove_unreachable_handlers_no_lp
Hi,
On Wed, 25 Jan 2012, Michael Matz wrote:
so, the below adjusted testcase from PR48794 still fails for the same
reasons (regions still referenced from RESX being removed). I was split
minds about if that's a new bug or just an extension of the old bug, so
I hijacked the old PR
Hi,
On Sat, 21 Jan 2012, Eric Botcazou wrote:
Trivially fixing the thinko (iterating over (work bit-and
old_conflict) in the first inner loop) would fix the testcase but in
general create too few conflicts, i.e. generate wrong code. I need
some time to think about this again.
OK,
Hi,
On Fri, 20 Jan 2012, Eric Botcazou wrote:
Is it supposed to change the generated code or...?
It was supposed to not change the set of conflicts, no. But I made a
thinko, and sometimes too many conflicts are generated. On the testcases
I tried that wasn't the case, so thanks for finding
Hi,
the stack-var conflict generation code needs 13 (out of 34) seconds, with
-O0 on the second testcase of PR46590. Most of the time is spent in
generating the same conflicts again and again at each basic block (the
time right now is O(nr-of-bbs * N^2) where the number of conflicts is
Hi,
On Sat, 7 Jan 2012, Peter Bergner wrote:
While digging through ira-color.c tracking down an IRA shuffle copy
issue, I noticed we only seem to do real copy coalescing for spilled
pseudos. It seems we rely on coloring to try and assign the same hard
reg to pseudos connected by a copy so
Hello,
On Fri, 9 Dec 2011, Jakub Jelinek wrote:
I had to tweak a little bit the expander conflict checking, because
if we have a BB with two incoming EH edges and clobber stmts from both
sunk into its beginning, then it would consider both variables (a and b
above) to be live at the same
Hi,
On Fri, 9 Dec 2011, Georg-Johann Lay wrote:
This is pretty much straight forward, and I don't understand the problems with
- canonicalize stuff
- optimize on canonicalized representation
- lower canonicalized representation to best RTL
I don't think anyone would reject patches that do
Hi,
On Mon, 12 Dec 2011, Jakub Jelinek wrote:
Looks cleaner, yes.
Just I wonder:
1) what if a bb contains no real insns (I know, they should be optimized
out, but do we assert that etc.?) - then the EXECUTE_IF_SET_IN_BITMAP
loop just wouldn't be done. Perhaps that is fine, it would
Hi,
On Mon, 12 Dec 2011, Jakub Jelinek wrote:
Ok. So, I'm happy with your changes and rth already acked the tree-eh.c
side, so can we just get an ack on these cfgexpand.c changes? Thanks.
Hmpf, I would have simply committed without a re-approval, but if you
think it's necessary I'll wait.
Hi,
On Thu, 8 Dec 2011, Richard Guenther wrote:
What I am not sure is whether the coalescing algorithm or the
expanding procedure is wrong here.
The forwarding of _218 is wrong. TER shouldn't have marked it as being
able to forward (check the expand-detailed dump for the Replacing
Hi,
On Tue, 6 Dec 2011, Tom de Vries wrote:
what should be the 'next' returned by delete_insn?
There are exactly two calls of delete_insn that take the return value.
One (delete_insn_and_edges) just uses it to return it itself (and there
are no calls to delete_insn_and_edges that use the
Hi,
On Fri, 2 Dec 2011, Jeff Law wrote:
So while continuing to have the phis in the available expression table
is not useful beyond the current block, the equivalency created when a
redundant PHI is encountered is useful to keep.
That's why I said to only clear the avail_exprs stack/vect
Hi,
On Sun, 4 Dec 2011, Eric Botcazou wrote:
I'm just a bit worried about the name delete_label. delete_insn
(label) should always do the right thing for a pure deletion; the
point of the new routine is that it also moves instructions.
It only fixes things up though, so that the RTL
Hi,
On Fri, 2 Dec 2011, William J. Schmidt wrote:
on top of your current version. That ought to remove the added PHI
expressions (and only them) from the hash table but retain the
information of equality in the const_or_copies_stack. Checking the BB
wouldn't be required then.
Hi,
On Fri, 2 Dec 2011, Richard Guenther wrote:
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-12-01 Jakub Jelinek ja...@redhat.com
PR debug/50317
* tree-ssa-dce.c (remove_dead_stmt): Add a debug stmt when removing
as unnecessary a store
Hi,
On Fri, 2 Dec 2011, William J. Schmidt wrote:
- tree def = gimple_get_lhs (stmt);
+ /* If this is a PHI, we only want to consider it if all of its
+ arguments are SSA names (which are known to be defined in a
+ single place). This avoids errors when dealing with
Hi,
On Fri, 2 Dec 2011, William J. Schmidt wrote:
It seems like a fair amount of rip-up to avoid keeping the PHI state
around between blocks, so I just check to ensure the PHI definitions
occur in the same block before recording their equivalence.
Then you should at least mix the BB
Hi,
On Thu, 1 Dec 2011, Richard Guenther wrote:
As the default defs are already automatically handled by all our
ssa infrastructure (including warning and propagation machinery) I
think it would be best to generate such one instead of a clobber
for the RHS.
So like this?
I
Hi,
please use gcc-help@ for this type of questions.
On Tue, 29 Nov 2011, Nadezhda Ivanоvna Vyukova wrote:
I've explained the customer that by default char is treated
as signed char on our platform and therefore this program
does not conform ISO C90, as it causes the integer overflow
Hi,
On Tue, 29 Nov 2011, Robert Dewar wrote:
IMHO it would be better to issue a warning when a finite loop is
transformed to an infinite one (as a result of -ftree-vrp).
-Wstrict-overflow gives a warning in this program. This warning isn't
active by default. 4.1 didn't yet have
Hi,
On Mon, 28 Nov 2011, Jiangning Liu wrote:
One more question...
Can i = i.6_18; be sinked out of loop, because it doesn't have
memory
dependence with others?
With current trunk the stores to i, a_p, b_p and k are sunken after the
loop. (There are no aliasing problems
Hi,
On Thu, 24 Nov 2011, Jiangning Liu wrote:
One more question...
Can i = i.6_18; be sinked out of loop, because it doesn't have memory
dependence with others?
With current trunk the stores to i, a_p, b_p and k are sunken after the
loop. (There are no aliasing problems because the
Hi,
On Fri, 25 Nov 2011, Tom de Vries wrote:
Note that you actually can remove labels also if they are
!can_delete_label_p, if you use delete_insn (which you do). It will
replace such undeletable labels by a DELETED_LABEL note.
I tried that as well but ran into these errors in
Hi,
On Thu, 24 Nov 2011, Jakub Jelinek wrote:
When stmt is mem = {v} {CLOBBER};, then lhs is neither
SSA_NAME, but it doesn't satisfy gimple_assign_copy_p either.
With this patch it will set the new_tree also to the clobber,
making it clear that the next iteration uses unitialized variable.
Hi,
On Thu, 24 Nov 2011, Jakub Jelinek wrote:
On Thu, Nov 24, 2011 at 05:28:00PM +0100, Michael Matz wrote:
As the default defs are already automatically handled by all our ssa
infrastructure (including warning and propagation machinery) I think it
would be best to generate such one
Hi,
On Tue, 22 Nov 2011, Gary Funck wrote:
Thanks for the tip. Typically, we don't build with
--enable-checking=all, however ...
We build with --enable-checking=all when we're testing major changes,
moving GUPC to a new target architecture, etc.
In the past, it may have been slower,
Hi,
On Mon, 21 Nov 2011, Jakub Jelinek wrote:
On Mon, Nov 21, 2011 at 05:40:26PM +0100, Rainer Orth wrote:
2011-11-20 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.c (init_gcc_specs) [USE_SHARED_LIBGCC_FOR_EH]: Always use
libgcc_s.
* config/sol2.h [USE_GLD]
Hi,
there's a superfluous break in a switch in tree.c, which together with the
object clobbers confuses our warning machinery at -O0, leading to a
bootstrap fail for Tom. As we have testcases for that already in PR20681
there's no need in GCCs source base itself to contain something like
Hi,
On Tue, 22 Nov 2011, Gary Funck wrote:
It gots much worse, with --enable-checking=all in combination with
--enable-build-poststage1-with-cxx (the default, if c++ is built,
and --enable-bootstrap is asserted).
In fact, a build started last night on fast server hardware has yet
to
801 - 900 of 1254 matches
Mail list logo
