--- Comment #10 from hp at gcc dot gnu dot org 2006-06-14 15:08 ---
I can't help but thinking the code is valid and that this is a valid bug.
Arguably, it *might* be hard to fix, and we'll have to cop out and adjust the
documentation instead.
I mean, the "i" c
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org
--- Comment #12 from hp at gcc dot gnu dot org 2006-06-15 16:50 ---
In reply to comment #11, "i" *is* an appropriate constraint, if any.
I see the problem with the reduced test-case in comment #3,
so I'm going to limit the scope of my involvement to fixing that.
Hopeful
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC||hp at gcc dot gnu dot org
Status|UNCONFIRMED
--- Comment #6 from hp at gcc dot gnu dot org 2008-11-12 21:22 ---
No, NOT FIXED.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #7 from hp at gcc dot gnu dot org 2008-11-12 21:25 ---
(In reply to comment #6)
> No, NOT FIXED.
At least not at 141791, though I see related changes for 141798 that might have
fixed it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38094
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: target
AssignedTo: hp at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38350
--- Comment #1 from hp at gcc dot gnu dot org 2008-12-01 15:20 ---
Created an attachment (id=16801)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16801&action=view)
testcase
Change the last constraint from g to X and compile with 4.3-branch r142284 with
-O2 -march=v32
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #2 from hp at gcc dot gnu dot org 2008-12-04 21:17 ---
My autotester sees it too...
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
"almost" misallocated.
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc do
--- Comment #1 from hp at gcc dot gnu dot org 2008-12-05 04:48 ---
Created an attachment (id=16830)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16830&action=view)
preprocessed sysdeps/posix/spawni.c and the CRIS glibc port
Compile with -O2.
--
http://gcc.gnu.org/b
: hp at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last
--- Comment #2 from hp at gcc dot gnu dot org 2008-12-06 20:09 ---
If there was an ftruncate call in the execution path, then I'd see the
"required ftruncate or chsize support not present" message in the log, and I
don't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
--- Comment #4 from hp at gcc dot gnu dot org 2008-12-06 21:15 ---
(In reply to comment #3)
> Try this and let me know.
Will do.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
--- Comment #5 from hp at gcc dot gnu dot org 2008-12-06 21:33 ---
Sorry, it didn't help.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38430
--- Comment #6 from hp at gcc dot gnu dot org 2008-12-07 21:42 ---
I noticed something odd while looking at simulator traces: running the
test-case streamio_1 at -O1 (passing) yielded a different execution path than
at -O0 (failing) *in the library*. At -O0, no write system calls were
--- Comment #7 from hp at gcc dot gnu dot org 2008-12-07 21:51 ---
Created an attachment (id=16847)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16847&action=view)
valgrind -v output from streamio_1 compiled "-O2 -static" on
i686-unknown-linux-gnu (freshly upd
--- Comment #10 from hp at gcc dot gnu dot org 2008-12-08 23:25 ---
(In reply to comment #9)
> Please try this patch.
That did it! Thanks.
(Haven't checked whether this eliminates the valgrind complaints in the posted
trace, but the FAILs in this PR were fixed.)
br
--- Comment #12 from hp at gcc dot gnu dot org 2008-12-09 09:17 ---
.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
nedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC target triplet: cris-*-* and crisv32-*-* and other default-packed arches
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38457
edTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38574
--- Comment #1 from hp at gcc dot gnu dot org 2008-12-18 22:21 ---
Oops, forgot the code:
extern __thread char xyzzy[64] __attribute__ ((tls_model
("initial-exec")
#ifdef H
,
--- Comment #4 from hp at gcc dot gnu dot org 2008-12-18 22:35 ---
(In reply to comment #3)
> Actually this is expected behavior of -fvisibility=hidden IIRC.
Oh right, it's at the end of the doc paragraph.
Ok, I've done my share of the noise for today. :)
--
hp at gc
: 4.4.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux
--- Comment #1 from hp at gcc dot gnu dot org 2008-12-21 22:41 ---
Created an attachment (id=16955)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16955&action=view)
MMIX IRA_COVER_CLASSES patch
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
cute/built-in-
setjmp.c execute -O2 and above
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot o
--- Comment #2 from hp at gcc dot gnu dot org 2008-12-23 11:03 ---
The bug is still visible at r142016.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
--- Comment #2 from hp at gcc dot gnu dot org 2008-12-23 18:30 ---
(In reply to comment #1)
> I haven't read the whole RTL till the last phase, so I don't know where things
> went wrong, but I'm pretty sure the bug isn't in DSE and the recent changes,
It mi
--- Comment #3 from hp at gcc dot gnu dot org 2008-12-23 18:40 ---
And still visible at r142018...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
--- Comment #4 from hp at gcc dot gnu dot org 2008-12-23 22:12 ---
(In reply to comment #3)
> I couldn't spot any bug eyeballing the assembly (or final RTL dump), so can
> you
> please debug how this now fails at runtime (abort, corruption (where), etc.)?
"(
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|WAITING |NEW
Ever Confirmed|0 |1
Last reconfirmed
--- Comment #4 from hp at gcc dot gnu dot org 2008-12-31 10:17 ---
Ditto 142116 and 142117.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38603
--- Comment #5 from hp at gcc dot gnu dot org 2008-12-31 19:13 ---
Glancing at the assembly and simulator trace (no looking at rtl or tree dumps
yet), the value of "p" (sp after the first alloca) is somehow lost and after
the __builtin_longjmp we effectively strcmp (NULL, &qu
--- Comment #9 from hp at gcc dot gnu dot org 2009-01-02 18:44 ---
See comment #5. The subsequent commits were AFAIK not addressing it. I don't
have time to experiment right now, and as the bug only appeared (at the time)
with separate patches, I'm making it SUSPENDED. CC
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |SUSPENDED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37813
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: crisv32-axis-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-17 15:44 ---
Created an attachment (id=17128)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17128&action=view)
as mentioned
Use cc1plus -fpreprocessed locale-inst.ii -march=v32 -quiet -dumpbase
locale-inst.cc -dA -
--- Comment #2 from hp at gcc dot gnu dot org 2009-01-17 15:46 ---
Configured with /tmp/hptest/v32l/gcc/configure
--prefix=/n/common_data/comptools/cris-1.64-64 --target=crisv32-axis-linux-gnu
--with-gnu-ld --with-gnu-as --enable-checking
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from hp at gcc dot gnu dot org 2009-01-17 16:06 ---
Um, ok, it's __gnu_cxx::__numeric_traits_integer::__min
so the number as such is most likely valid. :)
Not sure if that number is supposed to be valid as a .sleb128 operand though.
I'd better assign this to
--- Comment #4 from hp at gcc dot gnu dot org 2009-01-17 16:12 ---
Trunk binutils accepts it but produces junk:
Contents of section .text:
80808080 80808080 807f
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
--- Comment #5 from hp at gcc dot gnu dot org 2009-01-17 16:15 ---
(In reply to comment #4)
> 80808080 80808080 807f
Silly me, that's the right sleb128 encoding, IIUC. Doh.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38896
--- Comment #6 from hp at gcc dot gnu dot org 2009-01-17 16:38 ---
(In reply to comment #3)
> I'd better assign this to myself and check.
FWIW, the assembler that complained was an old 2.12.something. There's a gcc
sleb128 configure check, but it doesn't check
--- Comment #7 from hp at gcc dot gnu dot org 2009-01-17 17:19 ---
So... fixing the sleb128 configure test (to check that this number is parsed
and handled correctly) is fairly simple, but should perhaps only be done for
targets that actually will use 64-bit numbers. If someone wants
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu, i686-unknown-linux-gnu
GCC target triplet: cris-*-* and crisv32-*-*
http://gc
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-20 03:57 ---
Created an attachment (id=17150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17150&action=view)
testcase
Compile at -O2. Run in simulator (note the linker option) or compile with -O2
-S and
--- Comment #2 from hp at gcc dot gnu dot org 2009-01-20 10:38 ---
To fit in gcc.dg/torture, the test needs a
/* { dg-do run } */
at the top.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38921
--- Comment #3 from hp at gcc dot gnu dot org 2009-01-21 03:46 ---
Created an attachment (id=17156)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17156&action=view)
Fix.
Looks like reorg.c wasn't to blame after all. Changes were made to
may_trap_or_fault_p that ma
--- Comment #4 from hp at gcc dot gnu dot org 2009-01-21 03:48 ---
Zdenek, could you please comment on comment #3?
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from hp at gcc dot gnu dot org 2009-01-21 03:53 ---
There's reason to believe the patch in PR38921, fixes this bug too, by divine
mockery. I haven't verified yet, though. It would destroy the suspense...
--
hp at gcc dot gnu dot org changed:
--- Comment #5 from hp at gcc dot gnu dot org 2009-01-21 04:17 ---
(In reply to comment #3)
> For may_trap_or_fault_p, the current only callers are
> resource.c (reorg.c's old friend) ...
Typo/thinko; it's actually reorg.c itself, resource.c isn't involved.
--
--- Comment #7 from hp at gcc dot gnu dot org 2009-01-21 22:00 ---
(In reply to comment #6)
> However, I suspect that all the places that use may_trap_after_code_motion_p
> in
> fact expect it to have MTP_AFTER_MOVE | MTP_UNALIGNED_MEMS semantics as well.
Me too.
> So I w
zable insn, postreload.c:395
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-23 16:33 ---
Created an attachment (id=17166)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17166&action=view)
test-case
Compile with -O2 -march=v32 -fno-tree-sra for cris-axis-elf (or
crisv32-axis-elf).
--
--- Comment #2 from hp at gcc dot gnu dot org 2009-01-23 17:08 ---
Created an attachment (id=17167)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17167&action=view)
Reduced test-case, suggested for gcc.dg/torture but untested in framework.
Also -fstrict-aliasing (the defa
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-24 21:34 ---
A test-case and a target would help here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38267
--- Comment #1 from hp at gcc dot gnu dot org 2009-01-25 20:25 ---
.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #7 from hp at gcc dot gnu dot org 2009-01-26 12:46 ---
(In reply to comment #6)
> Sounds like this could maybe be a dup of bug 38952, where the frame pointer
> is incorrectly calculated when setjmp saves it in the jmp_buf, and therefore
> restored to an incorrect
--- Comment #7 from hp at gcc dot gnu dot org 2009-01-27 01:48 ---
I'll try to fit in to check this weekend, thanks for asking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21321
--- Comment #13 from hp at gcc dot gnu dot org 2009-05-06 05:06 ---
(In reply to comment #12)
> HP, is this still a problem?
No, I guess Matz just forgot to close it. Done.
--
hp at gcc dot gnu dot org changed:
What|Removed |Ad
P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-axis-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-09 23:02 ---
Seen for cris-elf too.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-10 00:04 ---
Created an attachment (id=17839)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17839&action=view)
slightly reduced test-case
It's the second abort call that's executed, but removing the first c
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-10 19:26 ---
(In reply to comment #2)
> Well, if only -O1 fails now, it is almost definitely my patch.
It definitely is, there are no other authors in that revision range! :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40086
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-10 22:07 ---
cris-elf too...
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
CC
--- Comment #6 from hp at gcc dot gnu dot org 2009-05-11 19:40 ---
(In reply to comment #4)
> I meant my fwprop patch. :-)
That's the patch in that revision range, yes... (FWIW, $SRP is the subroutine
return pointer, valid to use as data storage if saved.)
It's a bit un
--- Comment #7 from hp at gcc dot gnu dot org 2009-05-11 20:47 ---
(In reply to comment #5)
> It's a latent bug somewhere, possibly in delayed branch scheduling?
With vs. without -fno-delayed-branch at 147274 seems to justify this blame.
Ugh.
I'll see if I can nail it.
--- Comment #8 from hp at gcc dot gnu dot org 2009-05-11 21:14 ---
I see at least one invalid dbr transformation. Assuming you can read m68k
assembler, I'm sure you'll have no problem gripping the important parts of:
subq 25,$r13
test.b [$r13+$r9.b]
-
--- Comment #9 from hp at gcc dot gnu dot org 2009-05-11 21:19 ---
(In reply to comment #8)
> dbr moves an increment of $r9 *over a use*
Actually, "copies", not "moves", which is even worse (sort of; like "how could
it be worse"). I'll take it.
--- Comment #11 from hp at gcc dot gnu dot org 2009-05-13 00:09 ---
Two insns above the assembly sequence for the delay-slot fill quoted above,
there used to be a "clear.d $r9". That insn is moved into a delay-slot in the
first reorg_pass_number round by fill_simple_dela
--- Comment #12 from hp at gcc dot gnu dot org 2009-05-13 13:09 ---
The relax_delay_slots (first) call finds that there's a branch to a redundant
insn that it can eliminate. It does this by redirecting the branch to a new or
existing label and deleting the insn, or rather move i
--- Comment #13 from hp at gcc dot gnu dot org 2009-05-14 00:12 ---
By chance I stumbled upon an old fix I did some years ago in which I changed a
use of next_active_insn to next_real insn (to avoid skipping USE insns). You
can see it in comments referring to a now-deleted "main
--- Comment #14 from hp at gcc dot gnu dot org 2009-05-14 01:18 ---
Created an attachment (id=17861)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17861&action=view)
patch for just the bug at hand.
This patch just changes the next_active_insn for the exposure in this PR.
--- Comment #15 from hp at gcc dot gnu dot org 2009-05-14 11:17 ---
patch posted after testing
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Keywords: wrong-code, build
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: cris-ax
--- Comment #1 from hp at gcc dot gnu dot org 2009-05-26 00:35 ---
Created an attachment (id=17914)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17914&action=view)
preprocessed code from compiling crtend.o
At a glance, one would believe some function in crtstuff.c is la
--- Comment #4 from hp at gcc dot gnu dot org 2009-05-26 03:27 ---
When porting code such as in the description, it can be argued that
robustifying the code is an important part; that undefined code that just
happened to "work" for the initial target(s) is corrected to u
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-26 04:42 ---
(In reply to comment #2)
> This sounds like either an as bug
An expression that is the difference between two *other* sections is not
regularly allowed for ELF targets...
> or a bug in the target back-end acc
--- Comment #5 from hp at gcc dot gnu dot org 2009-05-26 10:56 ---
(In reply to comment #4)
> -fno-inline-functions should probably be -fno-inline. -f[no-]inline-functions
> is semantically a no-op (it just tunes some params).
Thanks! Superficial testing (adding that option, d
--- Comment #6 from hp at gcc dot gnu dot org 2009-05-26 19:30 ---
(In reply to comment #4)
> -fno-inline-functions should probably be -fno-inline. -f[no-]inline-functions
> is semantically a no-op (it just tunes some params).
I've verified that is a fix, but it is cou
--- Comment #7 from hp at gcc dot gnu dot org 2009-05-26 19:44 ---
Changing to middle-end. Nothing near target-specific.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |hp at gcc dot gnu dot org
|dot org
--- Comment #8 from hp at gcc dot gnu dot org 2009-05-27 12:40 ---
Subject: Bug 40249
Author: hp
Date: Wed May 27 12:40:09 2009
New Revision: 147907
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147907
Log:
PR middle-end/40249
* Makefile.in (CRTSTUF
--- Comment #9 from hp at gcc dot gnu dot org 2009-05-27 12:40 ---
.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from hp at gcc dot gnu dot org 2009-05-27 17:56 ---
The referred patch was committed as r147712, so I presume this is now fixed.
--
hp at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from hp at gcc dot gnu dot org 2009-06-10 17:36 ---
(In reply to comment #7)
> I do think that bit operations in general
> could be handled a lot better, and that would help out a whole lot of code.
If you add (compilable) test-cases with enhancement requests, car
--- Comment #1 from hp at gcc dot gnu dot org 2009-06-12 13:19 ---
See also <http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00962.html>.
Not entering it in the patch field yet for reasons mentioned.
--
hp at gcc dot gnu dot org changed:
What|R
--- Comment #4 from hp at gcc dot gnu dot org 2009-06-16 02:28 ---
Mee too! I mean, seen for cris-elf too!
BTW, isn't it odd that for recent regressions, the committer's testing never
seem to have shown the regressions seen by "every other target" after commit?
--- Comment #5 from hp at gcc dot gnu dot org 2009-06-16 02:36 ---
To add something useful, I should have mentioned that they were ok for 148440,
regressed for 148444 for cris-elf, so that leaves only commit's from Aldy and
Steven B., IIUC.
--
http://gcc.gnu.org/bug
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40469
--- Comment #4 from hp at gcc dot gnu dot org 2009-06-18 05:49 ---
(In reply to comment #3)
> ... so this is actually a duplicate of bug 18501.
>
> *** This bug has been marked as a duplicate of 18501 ***
The loopness distinction for duplicate-marker seems bogus: PR22456 ha
--- Comment #6 from hp at gcc dot gnu dot org 2009-06-18 14:30 ---
(In reply to comment #5)
> See the difference now?
Thanks, that helped.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40469
--- Comment #6 from hp at gcc dot gnu dot org 2009-07-08 10:47 ---
(In reply to comment #0)
If it's just about the version, perhaps you can make -V working again.
Requires a working --enable-version-specific-runtime-libs of course. :)
--
http://gcc.gnu.org/bugzilla/show_bug.c
--- Comment #7 from hp at gcc dot gnu dot org 2009-07-08 10:49 ---
(In reply to comment #6)
> If it's just about the version, perhaps you can make -V working again.
Oh same version. Change the above to "make -b working again".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40458
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, build
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hp at gcc dot gnu dot org
GCC host tri
--- Comment #1 from hp at gcc dot gnu dot org 2009-08-11 00:18 ---
Created an attachment (id=18339)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18339&action=view)
Preprocessed ecvtbuf.c from months-old newlib
Compile with -O2 to reproduce ICE.
--
http://gcc.
--- Comment #2 from hp at gcc dot gnu dot org 2009-08-11 01:02 ---
I had a brief look. Seems like the new code assumes that promote_mode always
promotes the input mode (ahem! :) when mismatching, which it only does if the
target defines PROMOTE_MODE (which CRIS does not; it just has a
1 - 100 of 1403 matches
Mail list logo
