--- Comment #3 from rask at gcc dot gnu dot org 2007-12-26 17:25 ---
Created an attachment (id=14832)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14832&action=view)
patch v1
(gdb) frame 1
#1 0x0096e248 in gen_movdi (operand0=0x2ac241e195e0,
operand1=0x2ac241de1
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-21 22:20 ---
You want something like this in libgcc/config/avr/t-avr to get the 16-bit
versions:
# Extra 16-bit integer functions.
intfuncs16 = _absvXX2 _addvXX3 _subvXX3 _mulvXX3 _negvXX2 _ffsXX2 _clzXX2 \
_ctzXX2
--- Comment #20 from rask at gcc dot gnu dot org 2007-12-21 21:56 ---
Fixed as of revision 131125 on mainline and not a 4.1/4.2 regression.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from rask at gcc dot gnu dot org 2007-12-21 21:53 ---
Subject: Bug 8835
Author: rask
Date: Fri Dec 21 21:53:23 2007
New Revision: 131125
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131125
Log:
2007-12-13 Andrew Pinski <[EMAIL PROTECTED]>
--- Comment #18 from rask at gcc dot gnu dot org 2007-12-19 14:15 ---
Created an attachment (id=14795)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14795&action=view)
(u)mulsidi3 patch
This patch (in testing) improves the register allocation, removing the last
redunda
--- Comment #5 from rask at gcc dot gnu dot org 2007-12-18 15:58 ---
Fixed with revision 131037.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rask at gcc dot gnu dot org 2007-12-18 15:31 ---
Subject: Bug 33474
Author: rask
Date: Tue Dec 18 15:30:57 2007
New Revision: 131037
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131037
Log:
PR target/33474
* config/bfi
--- Comment #10 from rask at gcc dot gnu dot org 2007-12-16 15:18 ---
> That is not a regression Just an already existing failure.
OK, looks like an intermittent failure which happens about one out of four
times.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
--- Comment #9 from rask at gcc dot gnu dot org 2007-12-16 13:39 ---
> That is not a regression Just an already existing failure.
Unmodified trunk revision 130944 doesn't have it:
diff -u build/arm-unknown-elf-results-unpatched/summary
build/arm-unknown-elf-results
--- Comment #7 from rask at gcc dot gnu dot org 2007-12-16 12:55 ---
It's the dataflow merge (125624) that broke it. Revision 125623 with 130333 on
top is fine, but 125624 with 125851 (so it builds) and 130333 on top fails.
The patch in comment #6 has one testsuite regression o
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-13 22:01 ---
In reply to comment #2 from Torbjorn Granlund:
> Another fix would perhaps be to teach synth_mult to understand that
> it's generating code for a 2.5 operand machine (one that can only
> do "a x=
--- Comment #5 from rask at gcc dot gnu dot org 2007-12-12 00:31 ---
See also bug 18560. I.e. consider using a C version instead.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34436
--- Comment #18 from rask at gcc dot gnu dot org 2007-12-10 21:03 ---
Mainline revision 130699:
/n/11/rask/build/gcc-mcore-unknown-elf/mcore-unknown-elf/libstdc++-v3/include/iomanip:
In function 'std::_Setfill<_CharT> std::setfill(_CharT) [with _CharT = char]':
/n/1
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-10 20:42 ---
Broken prologue expander, notice the mode mismatch: (plus:QI (reg/f:HI
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34412
--- Comment #2 from rask at gcc dot gnu dot org 2007-12-05 17:00 ---
And the configure arguments:
--target bfin-unknown-elf --enable-checking=yes,rtl --with-newlib --enable-sim
--disable-gdb --disable-nls --disable-libffi --disable-target-libffi
--disable-boehm-gc --disable-target-boehm
--- Comment #1 from rask at gcc dot gnu dot org 2007-12-05 16:52 ---
Created an attachment (id=14701)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14701&action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34350
s: ice-on-valid-code, build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
GCC target triplet: bfin-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34350
--- Comment #1 from rask at gcc dot gnu dot org 2007-12-05 13:50 ---
*** This bug has been marked as a duplicate of 33777 ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from rask at gcc dot gnu dot org 2007-12-05 13:50 ---
*** Bug 34349 has been marked as a duplicate of this bug. ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rask at gcc dot gnu dot org 2007-12-03 17:52 ---
Note that reload asks for Q_REGS when the constraints allow GENERAL_REGS, so
the root cause is just reload being stupid. I bet it is this optimization from
find_reloads() that causes it:
if (! win
--- Comment #3 from rask at gcc dot gnu dot org 2007-12-03 17:34 ---
Created an attachment (id=14695)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14695&action=view)
testcase
This testcase fails with revision 130561.
./xgcc -B./ -O2 /tmp/hashtab.c -S -o /dev/null
(gd
--- Comment #6 from rask at gcc dot gnu dot org 2007-12-01 22:39 ---
Created an attachment (id=14678)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14678&action=view)
patch v2
The first patch caused build failure on sh and arm, this one fixes that.
--
rask at gcc dot
--- Comment #11 from rask at gcc dot gnu dot org 2007-11-29 00:09 ---
In reply to comment #10 from Steven Bosscher 2007-11-28 22:02:
> > + for (defs = DF_INSN_DEFS (insn);
> > + *defs && DF_REF_REGNO (*defs) != REGNO (x);
> > + defs++)
>
--- Comment #8 from rask at gcc dot gnu dot org 2007-11-28 22:07 ---
Created an attachment (id=14658)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14658&action=view)
example patch
This patch is an example of the suggestion in comment #6. When compiling with
-S -dp, it i
--- Comment #9 from rask at gcc dot gnu dot org 2007-11-28 18:01 ---
Created an attachment (id=14657)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14657&action=view)
Patch v2 to enhance cse.c
This patch also handles unsigned comparisons and thus optimizes the original
t
--- Comment #15 from rask at gcc dot gnu dot org 2007-11-28 01:55 ---
Fixed for both 4.2.3 and 4.3.0.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from rask at gcc dot gnu dot org 2007-11-28 01:44 ---
Subject: Bug 34174
Author: rask
Date: Wed Nov 28 01:44:10 2007
New Revision: 130489
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130489
Log:
Backport from mainline:
2007-11-26 Rask
--- Comment #8 from rask at gcc dot gnu dot org 2007-11-27 18:04 ---
Created an attachment (id=14647)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14647&action=view)
Patch to enhance cse.c
The attached patch can optimize this testcase:
void foo (int);
int bar2 (int a
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rask at gcc dot gnu dot org
|dot org
--- Comment #4 from rask at gcc dot gnu dot org 2007-11-26 18:14 ---
Created an attachment (id=14643)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14643&action=view)
patch v1
This patch makes the ICE go away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34226
--- Comment #3 from rask at gcc dot gnu dot org 2007-11-26 17:27 ---
This seems to have started with revision 130333, but I don't think that change
is to blame:
(gdb) bt
#0 frv_secondary_reload_class (class=ICC_REGS, mode=BImode, x=0x2b0f0ec48d80,
in_p=0) at /n/12/rask/src/al
--- Comment #13 from rask at gcc dot gnu dot org 2007-11-26 13:20 ---
Subject: Bug 34174
Author: rask
Date: Mon Nov 26 13:20:19 2007
New Revision: 130438
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130438
Log:
PR target/34174
* config/fr3
ersion: 4.3.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
GCC target triplet: frv-unkno
--- Comment #16 from rask at gcc dot gnu dot org 2007-11-23 20:43 ---
(In reply to comment #
> I think the bug can be closed as fixed now.
I'm not so convinced. This part
> leal(%ecx,%edx), %esi
> movl%esi, %edx
> movl4(%esp), %esi
--- Comment #11 from rask at gcc dot gnu dot org 2007-11-23 13:46 ---
> dp-bit.c:964: internal compiler error: in change_address_1, at
> emit-rtl.c:1783
That is because it needs an offsetted address during and after reload, and the
fr30 doesn't have that. It can happen o
--- Comment #10 from rask at gcc dot gnu dot org 2007-11-23 01:33 ---
I think both branches of "if (reverse)" could use the exact same code, i.e.
this whole reverse/!reverse idea is bogus on fr30. Suppose our output registers
are r1 and r2 and we receive the address in rN. The
--- Comment #8 from rask at gcc dot gnu dot org 2007-11-22 13:54 ---
Created an attachment (id=14607)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14607&action=view)
patch v2 for GC 4.2.2
Weird. I don't understand why GCC 4.2.2 is having problems with that. This
pa
--- Comment #6 from rask at gcc dot gnu dot org 2007-11-22 12:31 ---
Created an attachment (id=14605)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14605&action=view)
patch v1 for GCC 4.2.2
Here's a different patch which hopefully doesn't ICE on GCC 4.
--- Comment #14 from rask at gcc dot gnu dot org 2007-11-21 19:11 ---
> it is preferrable to avoid including any headers in
> testcases if possible.
Yes, but IMHO not at the cost of disabling the test on targets where it is
supposed to run and pass. Targets without stdint.h ar
--- Comment #3 from rask at gcc dot gnu dot org 2007-11-21 15:40 ---
Created an attachment (id=14592)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14592&action=view)
patch v1 for GCC 4.3
Please use -dp when posting asm output because it makes it easier to see what
is g
--- Comment #3 from rask at gcc dot gnu dot org 2007-11-21 14:44 ---
Strictly speaking, it is a bug that building in the source tree doesn't work,
but IIRC, the instructions on building GCC do mention that building in the
source tree doesn't work, and no fix seem likely any
--- Comment #11 from rask at gcc dot gnu dot org 2007-11-20 20:04 ---
> /* { dg-do run { target { int32plus } } } */
Or even better, use types such as uint_least32_t from stdint.h, then use this
dg directive:
/* { dg-do run { target { stdint_types } } } */
--
http://gcc.gnu.
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-20 19:46 ---
*** This bug has been marked as a duplicate of 32287 ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from rask at gcc dot gnu dot org 2007-11-20 19:46 ---
*** Bug 34165 has been marked as a duplicate of this bug. ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-20 19:30 ---
If you don't build in a combined tree, you'll have to build and install
binutils and newlib before you can build some of the gcc components, such as
libssp. This means building gcc twice; first with --disa
--- Comment #16 from rask at gcc dot gnu dot org 2007-11-17 12:19 ---
A directive which allows a test to increase the timeout to x times the normal
timeout would probably be a good idea. A few of the tests take much longer than
most and IMO their timeout should be set based on the
--- Comment #4 from rask at gcc dot gnu dot org 2007-11-14 19:10 ---
For f(), combine wants a pattern to match
(set (reg:DI 76)
(sign_extend:DI (subreg:SI (plus:DI (subreg:DI (mult:SI (reg:SI 16 $16 [ x
])
(const_int 4 [0x4])) 0)
(reg:DI 17
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-14 01:44 ---
With -S -dp it is clear that only byte0 is optimized:
byte0:
movzbl 4(%esp), %eax # 11*movqi_1/3
byte1:
movl4(%esp), %eax # 24*movsi_1/1
movl8(%esp), %edx # 25
--- Comment #16 from rask at gcc dot gnu dot org 2007-11-10 01:32 ---
Two testcases which aren't optimized:
unsigned int bad1 (unsigned int a)
{
unsigned int c = a - 1;
if (c > a)
abort ();
else
return c;
}
unsigned int bad2 (unsigned int a)
{
unsigned int c
--- Comment #2 from rask at gcc dot gnu dot org 2007-11-10 01:21 ---
I can't reproduce this with revision 127331 or 129967.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33474
--- Comment #4 from rask at gcc dot gnu dot org 2007-11-10 00:59 ---
We are regressing! Number of asm lines, not counting directives:
4.1.2: 88
4.2.0: 80
4.2.1: 80
4.2.2: 80
4.3.0: 100 (revision 129967)
--
rask at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from rask at gcc dot gnu dot org 2007-11-10 00:15 ---
This was fixed in 4.3.0.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rask at gcc dot gnu dot org 2007-11-09 23:51 ---
This has improved (-O2 -fomit-frame-pointer):
test:
movl4(%esp), %eax # 32*movsi_1/1 [length = 4]
movl8(%esp), %edx # 44*movsi_1/1 [length = 4]
orl %eax, %edx
--- Comment #7 from rask at gcc dot gnu dot org 2007-11-09 20:40 ---
This has been fixed for more than a year:
reverse:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
eor r3, r0, r0
--- Comment #4 from rask at gcc dot gnu dot org 2007-11-09 19:48 ---
I think this might be a middle-end issue related to PR 7061 or PR 15184. We're
doing slightly better with GCC 4.3.0 (because of subreg lowering, I guess), but
not much (asm output with -dp for readability
--- Comment #2 from rask at gcc dot gnu dot org 2007-11-09 11:58 ---
Tested revision 129966 which works.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-09 11:54 ---
Created an attachment (id=14514)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14514&action=view)
patch v1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33474
--- Comment #2 from rask at gcc dot gnu dot org 2007-11-09 11:08 ---
It's not unusual to need more than one instruction pattern for the same machine
instruction. See http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01318.html>
and the followup for a recent example and what you can
--- Comment #1 from rask at gcc dot gnu dot org 2007-11-09 10:45 ---
Created an attachment (id=14513)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14513&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
NCONFIRMED
Keywords: ice-on-valid-code, build
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
GCC target triplet: sh-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34040
--- Comment #4 from rask at gcc dot gnu dot org 2007-11-07 16:35 ---
Francois-Xavier, do you still see a performance regression? If so, please post
asm output (-S -dp) from both versions?
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from rask at gcc dot gnu dot org 2007-11-06 20:14 ---
Subject: Bug 32787
Author: rask
Date: Tue Nov 6 20:14:22 2007
New Revision: 129944
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129944
Log:
2007-11-06 Rask Ingemann Lambertsen <[EMAI
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rask at gcc dot gnu dot org
|dot org
--- Comment #12 from rask at gcc dot gnu dot org 2007-10-31 15:00 ---
> That's IMHO wrong, you are changing the meaning of < constraint.
Yes, I see what you mean, they ('<' and '>') are defined independently of stack
direction. They should howe
--- Comment #10 from rask at gcc dot gnu dot org 2007-10-31 14:44 ---
Oops, I'm sorry about stealing your bug, Jakub. I didn't see you had taken it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31507
--- Comment #9 from rask at gcc dot gnu dot org 2007-10-31 14:37 ---
Created an attachment (id=14448)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14448&action=view)
patch for testing
This seems to be a simple mismatch between what push_operand() accepts and what
matc
--- Comment #17 from rask at gcc dot gnu dot org 2007-10-30 00:14 ---
Created an attachment (id=14438)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14438&action=view)
patch v3, varargs free
In reply to comment #16:
> You can cast them at the time of calling and sto
--- Comment #5 from rask at gcc dot gnu dot org 2007-10-29 15:11 ---
Is it possible to reproduce this on x86_64-unknown-linux-gnu somehow? I've
tried to no avail with -Os and -mregparm=0 -Os on both testcases. What is a
known bad revision?
--
http://gcc.gnu.org/bug
--- Comment #9 from rask at gcc dot gnu dot org 2007-10-28 17:48 ---
I just tried with only the alloca patch, and despite the unsplit insn-attrtab.c
file, process size tops at just 205 MB. It looks like GCC 4.3.0 is in a much
better shape than GCC 4.1.1, so I'm letting go of th
--- Comment #15 from rask at gcc dot gnu dot org 2007-10-28 15:54 ---
In reply to comment #14:
> is your patch supposed to help with testcase presented in comment #6?
No, it's aimed at the problem from the description. That is, GCC itself doesn't
work if compiled with a c
--- Comment #13 from rask at gcc dot gnu dot org 2007-10-28 14:02 ---
In reply to comment #7:
> I need it to build GCC with OpenWatcom, which wants parameters on the stack
> by default.
Er, that's in registers by default, of course.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #12 from rask at gcc dot gnu dot org 2007-10-28 14:00 ---
In reply to comment #11:
> How many times do I have to say this is bad for most RISC targets (hosts)?
I don't particularily care how many times you say it. Show some code (which
works) and/or show some tim
--- Comment #8 from rask at gcc dot gnu dot org 2007-10-28 12:57 ---
Created an attachment (id=14421)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14421&action=view)
split insn-attrtab.c into three files
Here's the patch to split insn-attrtab.c into smaller pieces
--- Comment #7 from rask at gcc dot gnu dot org 2007-10-28 12:40 ---
Created an attachment (id=14420)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14420&action=view)
Reenable alloca() on non-GCC compilers
The memory fragmentation problem is to be caused by libibert
--- Comment #10 from rask at gcc dot gnu dot org 2007-10-28 11:14 ---
Created an attachment (id=14419)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14419&action=view)
patch v2, i386 fix added
--
rask at gcc dot gnu dot org changed:
What|
--- Comment #9 from rask at gcc dot gnu dot org 2007-10-27 23:36 ---
It happens to work because all the compilers people use to build GCC pass
varargs the same way as non-varargs, at least for the number of arguments
received by the gen_* functions. IOW you shouldn't see any
--- Comment #7 from rask at gcc dot gnu dot org 2007-10-27 23:16 ---
Created an attachment (id=14417)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14417&action=view)
possible patch
Please give this patch a try. I need it to build GCC with OpenWatcom, which
wants parame
--- Comment #6 from rask at gcc dot gnu dot org 2007-10-27 15:24 ---
Tested revision 129548 which works.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-27 13:40 ---
This is not a regression (as far as I know), so it won't be fixed in anything
earlier than 4.3.0.
GCC dies trying to figure out which of BYTE PTR, WORD PTR, etc. it should print
for a structure. You may be able to
--- Comment #4 from rask at gcc dot gnu dot org 2007-10-27 13:40 ---
*** Bug 33918 has been marked as a duplicate of this bug. ***
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rask at gcc dot gnu dot org 2007-10-27 12:46 ---
As far as I can tell (from running cc1 in a debugger), the problem is not so
much the size of the file, but that it contains two large functions and GCC
leaks memory. After compiling the first large function, the
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-25 18:58 ---
I see a substantial improvent when testing on the compile farm hardware:
processor : 3
vendor_id : AuthenticAMD
cpu family : 15
model : 65
model name : Dual-Core AMD Opteron(tm
--- Comment #7 from rask at gcc dot gnu dot org 2007-10-25 18:04 ---
This works fine in 4.3. Looking at the commit log, I'd say it was fixed by
revision 121981.
--
rask at gcc dot gnu dot org changed:
What|Removed |
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-22 14:00 ---
This works with revision 129548, which I think is the one that fixed it.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-22 13:47 ---
http://sourceware.org/ml/binutils/2004-06/msg00419.html
It was bug in gas. The testcase works these days.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from rask at gcc dot gnu dot org 2007-10-22 13:07 ---
Fixed as of revision 129548.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from rask at gcc dot gnu dot org 2007-10-22 13:06 ---
Fixed as of revision 129548.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from rask at gcc dot gnu dot org 2007-10-22 11:51 ---
Subject: Bug 29473
Author: rask
Date: Mon Oct 22 11:50:56 2007
New Revision: 129548
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129548
Log:
PR target/29473
PR target/29493
--- Comment #5 from rask at gcc dot gnu dot org 2007-10-22 11:51 ---
Subject: Bug 29493
Author: rask
Date: Mon Oct 22 11:50:56 2007
New Revision: 129548
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129548
Log:
PR target/29473
PR target/29493
Component: pch
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33829
ReportedBy: rask at gcc dot gnu dot org
GCC target triplet: m32c-unknown-elf avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33782
--- Comment #3 from rask at gcc dot gnu dot org 2007-10-03 22:13 ---
You could open a request for a warning when a null pointer check is optimized
away after dereferencing the pointer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33629
--- Comment #1 from rask at gcc dot gnu dot org 2007-10-02 18:08 ---
This behaviour is as documented.
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from rask at gcc dot gnu dot org 2007-09-30 20:35 ---
Please look in your config.log for messages from collect2 and post the last
linker failure one plus any that look wrong.
--
rask at gcc dot gnu dot org changed:
What|Removed
--- Comment #18 from rask at gcc dot gnu dot org 2007-09-26 21:06 ---
I ran into this with 4.3 a few weeks ago.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rask at gcc dot gnu dot org 2007-09-25 12:05 ---
It works for me too at revision 128761.
--
rask at gcc dot gnu dot org changed:
What|Removed |Added
tatus: UNCONFIRMED
Keywords: ice-on-valid-code, ice-checking
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rask at gcc dot gnu dot org
GCC target triplet: m32c-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33551
--- Comment #13 from rask at gcc dot gnu dot org 2007-09-20 09:55 ---
> Are you telling me that *any* integer overflow allows a compiler to generate a
> buggy code without any notice ?
No, unsigned integer overflow is well defined.
--
http://gcc.gnu.org/bugzilla/show_bug.
--- Comment #5 from rask at gcc dot gnu dot org 2007-09-19 16:39 ---
table_init:
pushl %ebp# 51*pushsi2[length = 1]
movl$117835012, %eax# 20*movsi_1/1 [length = 5]
movl%esp, %ebp # 52*movsi_1/1 [length = 2
--- Comment #3 from rask at gcc dot gnu dot org 2007-09-19 16:12 ---
Technically, the code is undefined (overflow of signed integer val). Using -O2
-fno-strict-overflow results in a loop test, but the code looks dubious:
table_init:
pushl %ebp# 51*pushsi2
1 - 100 of 157 matches
Mail list logo
