--- Comment #6 from matz at gcc dot gnu dot org 2009-12-19 02:33 ---
Ah, because the references to trees are not handled via the write_cache
hashtable, but via the per-kind stream (in output_block.decl_state), which
is not realloced on create_output_block, but only on
lto_push
--- Comment #19 from matz at gcc dot gnu dot org 2009-12-20 01:16 ---
Subject: Bug 42027
Author: matz
Date: Sun Dec 20 01:15:46 2009
New Revision: 155367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155367
Log:
PR tree-optimization/42027
* cfg
--- Comment #12 from matz at gcc dot gnu dot org 2010-01-13 12:08 ---
The ABI (http://www.x86-64.org/documentation/abi.pdf) now contains this
language:
When a value of type \code{_Bool} is returned or passed in a register or
on the stack, bit 0 contains the truth
--- Comment #14 from matz at gcc dot gnu dot org 2010-01-13 14:33 ---
Yeah, I started to use micro version numbers, but I can't write to the html
file on that webserver, only to the subdirectory containing the PDFs. See
http://www.x86-64.org/documentation/
for a listing. The cu
--- Comment #16 from matz at gcc dot gnu dot org 2010-01-13 14:49 ---
We have a mailing list already, I don't think we need another one.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42324
--- Comment #3 from matz at gcc dot gnu dot org 2010-01-14 15:56 ---
This code and var-tracking was developed in parallel, that's why debug insns
are sometimes not handled correctly in the new out-of-ssa stuff. In this
case debug insns should probably be ignored, and not le
--- Comment #5 from matz at gcc dot gnu dot org 2010-01-14 16:17 ---
I don't think the big hammer is necessary. trivially_conflicts_p only is a
heuristic predicate influencing how other code is emitted. That other code
needs to handle them already, otherwise more transformations
--- Comment #3 from matz at gcc dot gnu dot org 2010-01-15 15:06 ---
input_location handling is broken.
(gdb) bt
#0 0x7704a7c3 in strcmp () from /lib64/libc.so.6
#1 0x011be858 in splay_tree_splay (sp=0x1824110, key=0)
at ../../gcc/libiberty/splay-tree.c:148
#2
--- Comment #20 from matz at gcc dot gnu dot org 2010-01-16 20:10 ---
It obviously could do the same. It all depends on the answer to this
question:
Do we want to deal with this via canonicalization of expressions, and if
yes, then also on the outcome of our discussion of where
--- Comment #2 from matz at gcc dot gnu dot org 2010-01-19 15:49 ---
What's the brokenness? The missing upper bound in the subrange type?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
--- Comment #16 from matz at gcc dot gnu dot org 2010-01-19 16:06 ---
Subject: Bug 41783
Author: matz
Date: Tue Jan 19 16:05:57 2010
New Revision: 156043
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156043
Log:
PR tree-optimization/41783
* tree-da
--- Comment #9 from matz at gcc dot gnu dot org 2010-01-20 14:42 ---
See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35418#c8
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41879
--- Comment #2 from matz at gcc dot gnu dot org 2010-01-27 17:28 ---
I'm testing a patch. It's target code, not ssa expand.
--
matz at gcc dot gnu dot org changed:
What|Removed
--- Comment #3 from matz at gcc dot gnu dot org 2010-01-28 14:12 ---
Subject: Bug 42881
Author: matz
Date: Thu Jan 28 14:11:34 2010
New Revision: 156320
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156320
Log:
PR target/42881
* config/i38
--- Comment #4 from matz at gcc dot gnu dot org 2010-01-28 14:40 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #28 from matz at gcc dot gnu dot org 2010-01-31 20:34 ---
fejj: To see how your initial code is broken, I've transformed it a bit to
show you how it already is "miscompiled" with earlier compilers. I've manually
unrolled the loop, and hoisted the two
--- Comment #3 from matz at gcc dot gnu dot org 2010-02-01 00:21 ---
3.4 had this as initial RTL:
(insn 3 2 4 (set (reg:DI 60)
(mem/f:DI (reg/f:SI 53 virtual-incoming-args) [2 a+0 S8 A32])) -1 (nil)
(expr_list:REG_EQUIV (mem/f:DI (reg/f:SI 53 virtual-incoming-args)
[2
--- Comment #4 from matz at gcc dot gnu dot org 2010-02-01 02:41 ---
Well, actually it depends. The code generated by 3.4 might theoretically
be slower, because it potentially uses a misaligned stack slot (incoming
stack with -m32 only 4 byte aligned). With -mpreferred-stack-boundary
--- Comment #5 from matz at gcc dot gnu dot org 2010-02-01 02:53 ---
He, Alan already conjectured this problem:
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg01182.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42919
--- Comment #18 from matz at gcc dot gnu dot org 2010-02-01 03:13 ---
See comment #11
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42898
--- Comment #7 from matz at gcc dot gnu dot org 2010-02-01 11:53 ---
Or making STRICT_ALIGNMENT depend on the type or mode. So that e.g.
"!align(8) && align(4) && !STRICT_ALIGN(long long)" would be acceptable,
but "!align(16) && STRICT_ALIGN(m12
--- Comment #30 from matz at gcc dot gnu dot org 2010-02-01 12:24 ---
See comment #3 for how (newer) GCC does warn at line 15. Not with the default
options, though, but this has good reasons (too many false positives).
You are right that we should be able to improve our diagnostics in
--- Comment #6 from matz at gcc dot gnu dot org 2010-02-04 15:03 ---
Re comment #4, there are two possibilities to fix this:
1) as you say, don't regard MEM addresses (i.e. used in double indirection)
as const_or_frame_p, because that would put different (but runtime-same)
--- Comment #5 from matz at gcc dot gnu dot org 2010-02-05 15:36 ---
The code for the if() looks sane on x86-64:
-
;; if (D.2729_8 != 0)
(insn 16 15 17 pr42972.c:10 (set (reg:QI 87)
(mem/s:QI (reg/f:DI 82 [ D.2727 ]) [0 S1 A32])) -1 (nil
--- Comment #9 from matz at gcc dot gnu dot org 2010-07-26 15:06 ---
Here's a testcase (nicer in the sense of not requiring inlining) that shows
the current compiler botching the nrv <-> retslot optimizations:
struct S {int x, y, makemelarge[5];};
S __attribute__((noinlin
--- Comment #20 from matz at gcc dot gnu dot org 2010-08-11 16:10 ---
A conforming variant of what you probably are trying to code is:
#include
#include
void format_indirect(char* dst_buffer, size_t
--- Comment #10 from matz at gcc dot gnu dot org 2010-08-12 16:00 ---
Ahh, it's just so entertaining.
C99 is a language, cdecl a calling convention. There is no 'cdecl compiler',
it makes no sense to speak about such a thing. cdecl is a calling convention
for function
--- Comment #27 from matz at gcc dot gnu dot org 2010-08-12 18:05 ---
Oh, this fun. Enjoyable, really! ;-)
So, you admit that MSVC does in fact "miscompile" your perfectly fine cdecl
code, if you request optimization from it? How bad is that of them?
Terrible! I woul
--- Comment #33 from matz at gcc dot gnu dot org 2010-08-12 18:56 ---
> Don't talk about what you don't know, you clearly know much less about the
> old days than me.
Well, I'll grant you that you know many wondrous and astounding "facts",
indeed.
--- Comment #35 from matz at gcc dot gnu dot org 2010-08-13 13:00 ---
> char* p1=(char*)0x3000; // address not pointing to any "C-object in the C99
> sense"
> char* p2=(char*)0x4000; // address not pointing to any "C-object in the C99
> sense"
>
&g
--- Comment #36 from matz at gcc dot gnu dot org 2010-08-13 13:14 ---
> > If you include real segmentation
> > like on 80286, where there's no linear relationship between effective
> > address and segment+offset, subtraction would have been prohibitively
>
--- Comment #41 from matz at gcc dot gnu dot org 2010-08-13 15:18 ---
You should really adjust your glasses if you want to continue trolling with
the high standards we're used to meanwhile:
> > What in the words "real segmentation like on 286, where there's no li
--- Comment #42 from matz at gcc dot gnu dot org 2010-08-13 15:25 ---
> > [ ] Yes
> > [x] No
>
> Thanks. The comunity will be alerted to this. I'll get back to you when
> your name is in some famous place associated with this claim.
That's very good. Th
--- Comment #51 from matz at gcc dot gnu dot org 2010-08-14 01:26 ---
> There you go, you are now famous.
> http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism
Thank you, that's encouraging, I just hope the language of that article won't
be changed too much
--- Comment #5 from matz at gcc dot gnu dot org 2010-08-15 21:07 ---
First, yes, the work-around from the official POSIX man-pages is alias-unsafe.
They added this example because ISO C doesn't allow conversion of void*
pointers to function pointer, but dlsym returns a void* po
--- Comment #8 from matz at gcc dot gnu dot org 2010-08-16 00:55 ---
Well, okay, (3) indeed is valid ISO C (no warning) and works on POSIX 2008.
I'd find it very awkward to write such work-around for (1) just so the
warning in strict ISO C mode is silenced. I find this case diff
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-02 12:58 ---
Mine. I'm adding some checking code too.
--
matz at gcc dot gnu dot org changed:
What|Removed |
s file from the sourcedir
of make.adb.
This is contrary to the documentation of '-I-' which is used here for a reason
I guess.
--
Summary: Ada bootstrap broken
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Prio
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-03 14:43 ---
Subject: Bug 45415
Author: matz
Date: Fri Sep 3 14:42:46 2010
New Revision: 163822
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163822
Log:
PR middle-end/45415
* tr
--- Comment #5 from matz at gcc dot gnu dot org 2010-09-03 14:46 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-07 13:24 ---
The remaining problem is the support for ncopies > 1 in
vectorizable_condition. http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00550.html
implements this.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43430
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-07 13:27 ---
The patch at http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00548.html
implements support for consecutive loads with negative step. It will
vectorize the first testcase. But not the second one because it only
handled
--- Comment #5 from matz at gcc dot gnu dot org 2010-09-07 13:42 ---
Since Ira implemented unaligned support in SLP mode we get somewhat further,
but not much. If complete unrolling is active that we can't disambiguate
between *s and *(s+stride). That is correct because stri
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-07 14:41 ---
Since the fix for PR44710 we can if-convert the conditions in the inner loop.
With http://gcc.gnu.org/ml/gcc-patches/2010-09/msg00542.html we also
make sure that the latch block isn't filled, which in turn
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-08 12:35 ---
Subject: Bug 33244
Author: matz
Date: Wed Sep 8 12:34:52 2010
New Revision: 163998
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163998
Log:
PR tree-optimization/33244
* tree-ss
--- Comment #8 from matz at gcc dot gnu dot org 2010-09-08 12:40 ---
Subject: Bug 43430
Author: matz
Date: Wed Sep 8 12:40:24 2010
New Revision: 163999
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=163999
Log:
PR tree-optimization/43430
* tree-vect
--- Comment #2 from matz at gcc dot gnu dot org 2010-09-13 14:21 ---
Uh, I just disabled tree-sinking in some cases. This can't be directly
the reason for the problem, rather it must have uncovered a latent problem.
Will try to investigate.
--
http://gcc.gnu.org/bug
--- Comment #3 from matz at gcc dot gnu dot org 2010-09-17 13:26 ---
Subject: Bug 43432
Author: matz
Date: Fri Sep 17 13:26:43 2010
New Revision: 164367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164367
Log:
PR tree-optimization/43432
* tree-vect-dat
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-17 13:45 ---
It might have been exposed by that revision, but that merely points out
a deficiency in RTL if conversion. The final gimple code doesn't have
explicit jumps in the inner loop, but uses cond_expr:
:
# s_22 = P
--- Comment #1 from matz at gcc dot gnu dot org 2010-09-17 16:12 ---
This passes for me, even in -m32 mode (if -msse is added, like vect.exp
does):
% ./cc1 -ftree-vectorize -fno-vect-cost-model -msse2 -O2 \
vect-114.c -ftree-vectorizer-verbose=2 2>&1 | grep note:
vect-114.c:1
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-20 11:07 ---
Whoops. Yeah, I only added x86_64-*-* to the vect_perm targets. Obviously,
as sse2 is active by default for the vectorizer testsuite I also need to
add the i?86-*-* targets. H.J., can you try with this patch on a
--- Comment #4 from matz at gcc dot gnu dot org 2010-09-20 13:17 ---
Yeah, probably some fold_convert is missing in reverse_vec_elements() in case
the type of the args or the return type of the chosen builtin decl don't
exactly match.
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #6 from matz at gcc dot gnu dot org 2010-09-20 14:12 ---
Subject: Bug 45706
Author: matz
Date: Mon Sep 20 14:12:04 2010
New Revision: 164433
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164433
Log:
PR testsuite/45706
* lib/target-supp
--- Comment #7 from matz at gcc dot gnu dot org 2010-09-20 14:14 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #8 from matz at gcc dot gnu dot org 2010-09-20 14:45 ---
Subject: Bug 45706
Author: matz
Date: Mon Sep 20 14:45:30 2010
New Revision: 164435
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=164435
Log:
PR testsuite/45706
* gcc.dg/vect/pr43432.
--- Comment #4 from matz at gcc dot gnu dot org 2010-05-05 12:35 ---
Ah, another case of a patch I held back for 4.6 to open, and then forgetting
about it :-/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
--- Comment #6 from matz at gcc dot gnu dot org 2010-05-05 13:32 ---
PRE seems to have done this since forever. All edge inserts are delayed if
the _immediate forms aren't used.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43984
--- Comment #9 from matz at gcc dot gnu dot org 2010-05-06 13:55 ---
Subject: Bug 43984
Author: matz
Date: Thu May 6 13:54:32 2010
New Revision: 159106
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159106
Log:
PR tree-optimization/43984
* tree-s
--- Comment #12 from matz at gcc dot gnu dot org 2010-06-10 12:26 ---
I don't think it ever was intended that 'm' includes operands with embedded
side-effects. I don't think so because making this work reliably is
relatively difficult. In particular the tests that
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-10 13:34 ---
> "m" is defined to be the most general memory constraint, and a pre/post
> modified memory operand is still a memory operand.
I know that this is the case, which is why I said: "If that means t
--- Comment #1 from matz at gcc dot gnu dot org 2010-06-15 11:19 ---
We have a slightly problematic ordering issue here. Here's what I
think should be made the case:
DECL_ALIGN should not matter after expansion, we have MEM_ALIGN for that.
(and for calculating offsets from
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-15 13:40 ---
Can you try to instead do the stack-estimation only when really_expand is
false? The issue is, we see all variables (or we _should_ see) exactly twice,
once for estimation, once for generating the DECL_RTL. The code
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-15 13:50 ---
Oh, and yes, I agree that in expand_one_stack_var_at (only called when
really_expand == true) we should limit align to $something. I'm just not
sure what $something is. crtl->stack_alignment_estimated is no
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-15 14:56 ---
Jakub was not talking about crtl->stack_alignment_estimated becoming 256,
but rather DECL_ALIGN of certain decls in expand_one_stack_var_at.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44542
--- Comment #2 from matz at gcc dot gnu dot org 2010-06-18 15:58 ---
It's not SSA expand (might be exposed by it, don't know), but the
bug is pre-existing already in 4.3:
long unsigned int D.2219;
struct S116 va_arg_tmp.3;
...
addr.0 = &va_arg_tmp.3;
addr.4 = (lon
--- Comment #4 from matz at gcc dot gnu dot org 2010-06-25 15:34 ---
Indeed. Mine.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #5 from matz at gcc dot gnu dot org 2010-06-28 15:14 ---
Subject: Bug 44592
Author: matz
Date: Mon Jun 28 15:14:31 2010
New Revision: 161496
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161496
Log:
PR middle-end/44592
* gimpl
--- Comment #6 from matz at gcc dot gnu dot org 2010-06-28 15:16 ---
Fixed for 4.6, waiting a bit for 4.5.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from matz at gcc dot gnu dot org 2010-06-29 11:31 ---
Can you perhaps run the testsuite without bootstrapping
(configure --disable-bootstrap; make; make check) to see if there occurs some
more obvious bug than a miscompilation of genmodes? Debugging bootstrap
--- Comment #7 from matz at gcc dot gnu dot org 2010-06-29 13:47 ---
Is /opt/gcc/gcc4.6bw/bin/gcc a bootstrapped compiler or one created without
bootstrapping?
The initial comment didn't reveal it, so maybe my assumption that it's a
miscompiled cc1 is wrong. So, just to
--- Comment #9 from matz at gcc dot gnu dot org 2010-06-29 14:48 ---
Yes, but I'm asking if it was a bootstrapped compiler (in difference to one
built with configuring with --disable-bootstrap) or not.
If it was a bootstrapped compiler, are you saying that bootstrap fails with
r1
--- Comment #11 from matz at gcc dot gnu dot org 2010-06-29 15:15 ---
I can reproduce now. It's also the non-bootstrapped compiler failing with
the testcase, thanks for that. I'm on it.
--
matz at gcc dot gnu dot org changed:
What|Removed
--- Comment #16 from matz at gcc dot gnu dot org 2010-06-30 16:34 ---
Subject: Bug 44699
Author: matz
Date: Wed Jun 30 16:34:22 2010
New Revision: 161614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=161614
Log:
PR bootstrap/44699
* tree-vrp.c (vrp_
--- Comment #17 from matz at gcc dot gnu dot org 2010-06-30 16:54 ---
Testcases are fixed. And according to
http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03137.html
we can probably also assume the bootstrap fail is fixed.
--
matz at gcc dot gnu dot org changed:
What
--- Comment #25 from matz at gcc dot gnu dot org 2010-07-07 11:15 ---
Due to SSA form the alias information reflects dependencies only between
accesses as if it ignores back edges. Hence any transformation that
transforms a back edge into a forward edge, or moves code over back edges
--- Comment #29 from matz at gcc dot gnu dot org 2010-07-07 12:10 ---
[just for completeness to not lose the thought:]
Thinking about this some more (triggered by the problem of not having nice
back edges in irreducible loops), it's not really the back edges that are
interesting bu
--- Comment #7 from matz at gcc dot gnu dot org 2007-10-22 15:29 ---
Subject: Bug 33855
Author: matz
Date: Mon Oct 22 15:29:17 2007
New Revision: 129551
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129551
Log:
PR tree-optimization/33855
* tree-ssa-
--- Comment #8 from matz at gcc dot gnu dot org 2007-10-22 15:32 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #3 from matz at gcc dot gnu dot org 2007-10-23 17:47 ---
Mine, have patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #4 from matz at gcc dot gnu dot org 2007-10-24 12:54 ---
Subject: Bug 33868
Author: matz
Date: Wed Oct 24 12:54:24 2007
New Revision: 129602
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129602
Log:
PR debug/33868
* var-tracking.c (variab
--- Comment #5 from matz at gcc dot gnu dot org 2007-10-24 12:55 ---
Fixed.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from matz at gcc dot gnu dot org 2007-10-31 21:52 ---
Working on it.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #11 from matz at gcc dot gnu dot org 2007-10-31 23:12 ---
Your threading testcase also seems to work with my patch. It doesn't fail
really reliably for me with the other compilers, so I'm not 100% certain,
can you check? Patch at
http://gcc.gnu.org/ml/gcc-pa
--- Comment #12 from matz at gcc dot gnu dot org 2007-11-01 03:06 ---
Subject: Bug 33961
Author: matz
Date: Thu Nov 1 03:06:38 2007
New Revision: 129817
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129817
Log:
PR tree-optimization/33961
* tree-ssa-
--- Comment #13 from matz at gcc dot gnu dot org 2007-11-01 03:11 ---
This one is fixed now.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from matz at gcc dot gnu dot org 2007-11-01 03:15 ---
I've checked in a patch for PR33961, which is similar to this one. Can
somebody check if anything here is still broken with trunk?
--
matz at gcc dot gnu dot org changed:
What|Re
--- Comment #8 from matz at gcc dot gnu dot org 2007-11-07 16:45 ---
When I analyzed this for the first time and finally found the root cause
my immediate reaction was "huh? we still have -fforce-addr?" . So, I also
wanted to get rid of it. But Richard had some reservatio
--- Comment #2 from matz at gcc dot gnu dot org 2007-11-22 04:26 ---
The problem starts already in the first iteration:
Value numbering destptr_3 stmt = destptr_3 = PHI
Setting value number of destptr_3 to dest_9
So, for now we assume dest_9 == destptr_3, quite okay, lets assume so
--- Comment #3 from matz at gcc dot gnu dot org 2007-11-22 04:31 ---
Created an attachment (id=14600)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14600&action=view)
incomplete fix
Concept patch touching only the unary case. binary, phi nodes and maybe
references wou
--- Comment #10 from matz at gcc dot gnu dot org 2007-11-22 14:07 ---
Created an attachment (id=14608)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14608&action=view)
my dump (without patch)
This is the dump I'm talking about. Richard uses a different compiler
--- Comment #11 from matz at gcc dot gnu dot org 2007-11-22 14:13 ---
Btw. canonicalization/rewriting on INSERT is indeed okay. As long as the hash
tables are deleted after every iteration (or otherwise invalidated). At least
the now provably false information needs to be removed
--- Comment #17 from matz at gcc dot gnu dot org 2007-11-22 22:51 ---
We could also save the deletes by using a tick counter, but with that patch
the hash tables will be mostly small anyway, so emptying them should be fast
enough I hope. And of course we won't get as optimal resul
ct: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: matz at gcc dot gnu dot org
GCC target triplet: s390-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
--- Comment #2 from matz at gcc dot gnu dot org 2007-11-27 19:05 ---
For reference, the internal one is at
https://bugzilla.novell.com/show_bug.cgi?id=344299
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
--- Comment #1 from matz at gcc dot gnu dot org 2007-11-27 19:02 ---
Created an attachment (id=14648)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14648&action=view)
fix for this
A potential fix for this problem, iterating over possibly multiple constant
refs. Shouldn
--- Comment #4 from matz at gcc dot gnu dot org 2007-11-28 15:28 ---
What I meant with "normal" code is by using inline asms. As it stands it's
impossible to write inline asm instructions having more than one literal pool
operand. I consider this normal use of the c
--- Comment #6 from matz at gcc dot gnu dot org 2007-11-28 15:59 ---
Yes, that would be a viable workaround. Perhaps even correct, given that
GCC can handle only MAX_RECOG_OPERANDS, which is only 30 at a minimum.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34250
--- Comment #18 from matz at gcc dot gnu dot org 2008-01-09 10:32 ---
It seems that this should work too: bitsize is 8 in this example IIRC, so
copy_mode would be byte_mode, which is what we need here. Additionally using
word_mode when we can seems worthwhile too.
One thing would
--- Comment #4 from matz at gcc dot gnu dot org 2008-04-25 15:12 ---
That's the layout of 'c', a pointer variable. We don't see the layout
of the record_type here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36043
--- Comment #8 from matz at gcc dot gnu dot org 2008-04-25 16:15 ---
FWIW, I think the error is in the caller of move_block_to_reg.
move_block_to_reg can make use of a load_multiple instruction, which really
loads full regs. I.e. it would be unreasonable to require changes in
301 - 400 of 411 matches
Mail list logo
