--- Comment #4 from matz at gcc dot gnu dot org 2008-05-08 15:13 ---
Hmm, actually I sort of agree with HJ. It's a global (and unhidden)
definition, which very well can be replaced by a different definition at
runtime. In particular that will happen for instance if the global da
--- Comment #8 from matz at gcc dot gnu dot org 2008-05-28 13:54 ---
Fixed in [EMAIL PROTECTED] Option now is -Wno-enum-compare .
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from matz at gcc dot gnu dot org 2008-07-01 19:17 ---
Blaeh. The bug is in code that is there since the dawn of revision control,
under a comment that starts with "... This is tricky ..." and ends with
"I am not sure whether the algorithm here is always r
--- Comment #10 from matz at gcc dot gnu dot org 2008-07-31 16:13 ---
I submitted a patch here:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00722.html
but got no feedback or review.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36613
--- Comment #50 from matz at gcc dot gnu dot org 2006-02-14 16:13 ---
Subject: Bug 22275
Author: matz
Date: Tue Feb 14 16:12:56 2006
New Revision: 110982
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110982
Log:
PR middle-end/22275
* stor-layout.c (lay
--- Comment #52 from matz at gcc dot gnu dot org 2006-02-15 12:19 ---
Subject: Bug 22275
Author: matz
Date: Wed Feb 15 12:19:49 2006
New Revision: 09
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=09
Log:
PR middle-end/22275
* stor-layout.c (lay
--- Comment #7 from matz at gcc dot gnu dot org 2006-11-10 15:47 ---
Just from looking at various places which handle ZERO_EXTRACT this seems to
by used highly inconsistent. E.g.:
rtlanal:nonzero_bits1: Doesn't look at BITS_BIG_ENDIAN or BYTES_BIG_ENDIAN at
all, but does us
--- Comment #8 from matz at gcc dot gnu dot org 2006-11-10 15:51 ---
At least this patch fixes the bug at hand, but I'm sceptical if by chance or
for real:
Index: ifcvt.c
===
--- ifcvt.c (revision 118648)
+++ if
--- Comment #10 from matz at gcc dot gnu dot org 2006-11-10 16:48 ---
Yes, I think all uses in combine.c are okay. In addition also the occurrence
in rtlanal.c is okay, as it doesn't use the bitpos, but the width in bits
to generate the mask, I just misread that part. I now look
--- Comment #4 from matz at gcc dot gnu dot org 2006-11-15 15:52 ---
Created an attachment (id=12623)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12623&action=view)
Assembler code
This is the assembler produced by gcc 4.1.0, in case someone needs the full
asm to de
--- Comment #42 from matz at gcc dot gnu dot org 2006-12-07 13:57 ---
I agree with Jan and HJ here. We must not emit symbols to unreferenced
symbols. Even the size increase wouldn't be really acceptable. In a way
ELF _is_ special here, so special handling is completely justified
401 - 411 of 411 matches
Mail list logo
