AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-03-04
00:48 ---
Created an attachment (id=8324)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8324action=view)
Suggested patch to correctly treat -0.0 and subnormals
No problem, here it is.
--
http://gcc.gnu.org
: UNCONFIRMED
Severity: normal
Priority: P2
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-04-07
13:56 ---
Created an attachment (id=8555)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8555action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20810
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-05-10
16:38 ---
As the bug reporter, I'm fine with that, although I can't really change the bug
to VERIFIED since I haven't.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19781
: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: mipsisa32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21738
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-elf
http
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-06-13
14:38 ---
Created an attachment (id=9080)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9080action=view)
Stripped down source file to reproduce problem
Compile with:
m68k-elf-gcc -c -m5200 -O1 -funit
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-06-13
14:48 ---
Oh, one interesting aspect is that the failure is even dependent on some of the
numbers in the switch statement. For example, if the penultimate number is 105
instead of 106 it compiles okay
--- Additional Comments From jifl-bugzilla at jifvik dot org 2005-06-13
15:01 ---
Oh, one more thing. The original version of the code, ICE'd on a slightly
different constraint:
(insn 1533 4485 1534 187
/home/jlarmour/ecos/ecospro-common-040929-branch/packages/net/snmp/lib/current/src
ReportedBy: jifl-bugzilla at jifvik dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19781
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: jifl-bugzilla at jifvik dot org
Created attachment 30966
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30966action=edit
libgcc patch to correct operation with non-interworking thumb builds
I have included a multilib
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
Jonathan Larmour jifl-bugzilla at jifvik dot org changed:
What|Removed |Added
CC
Assignee: unassigned at gcc dot gnu.org
Reporter: jifl-bugzilla at jifvik dot org
The following minimal test case (derived from much larger code) demonstrates a
problem which I could reproduce on m68k-elf-gcc 4.7.4. It can be built with
simply:
m68k-elf-gcc -c -O1 -fschedule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
Jonathan Larmour jifl-bugzilla at jifvik dot org changed:
What|Removed |Added
Known to fail||4.8.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #4 from Jonathan Larmour jifl-bugzilla at jifvik dot org ---
I have just double-checked, and my gcc 4.8.3 definitely doesn't generate the
'tstl', but it looks like you're bang on right about how gcc was configured: I
configured
--- Comment #13 from jifl-bugzilla at jifvik dot org 2009-01-07 18:03
---
The patch seems to be ok from my cursory checking, thanks!
Note that my original patch also included a trivial fix for concurrence.h where
__GTHREAD_MUTEX_INIT_FUNCTION was called when it should have been
--- Comment #9 from jifl-bugzilla at jifvik dot org 2009-01-27 21:07
---
I've just tried it on gcc 4.3.2 for arm-eabi, and can't reproduce it with
either 5.cc or 6.cc any more. -O0 or -O2 didn't make a difference either.
While the principle sort-of seems sound that you shouldn't push
: trivial
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37727
--- Comment #7 from jifl-bugzilla at jifvik dot org 2008-10-04 02:54
---
To avoid any uncertainty, I arranged a copyright assignment. Unfortunately the
FSF's copyright clerk left and there was a gap before the replacement started,
but it just so happens that today he confirmed
: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
GCC build triplet: i686-pc-linux-gnu
GCC host
--- Comment #1 from jifl-bugzilla at jifvik dot org 2008-10-24 02:39
---
Created an attachment (id=16535)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16535action=view)
Fix/workaround
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37905
--- Comment #8 from jifl-bugzilla at jifvik dot org 2008-10-30 13:10
---
Hi Benjamin, the copyright assignment is definitely sorted, and can be seen on
copyright.list on fencepost.gnu.org now.
Any reason for this not to go in (although I don't have commit perms)? Would it
better
--- Comment #2 from jifl-bugzilla at jifvik dot org 2008-10-30 13:15
---
In case it helps someone to look at this, I do have a copyright assignment for
GCC (although no commit access) so if this fix is acceptable, you can just
commit it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #6 from jifl-bugzilla at jifvik dot org 2009-10-14 22:39
---
Sorry yes, it was somewhat hard to replicable even with 3.3.3, and I was never
able to reproduce it with more recent GCC (but never quite satisfied myself
that it wasn't reproduceable!). Time to draw a line
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
GCC build triplet: i686-pc-linux-gnu
GCC
--- Comment #1 from jifl-bugzilla at jifvik dot org 2008-07-11 13:03
---
On thinking about this a bit more, I think this would be a regression for the
case where __GTHREAD_MUTEX_INIT is used. In the case of
__GTHREAD_MUTEX_INIT_FUNCTION, I believe the previous implementation was also
--- Comment #4 from jifl-bugzilla at jifvik dot org 2008-07-12 01:53
---
I can't really work out how to provide a testcase as such. To reproduce it all
I'm doing is:
#include cstdio
#include iostream
int
main(int argc, char *argv[])
{
std::cout Hello world std::endl;
return 0
--- Comment #5 from jifl-bugzilla at jifvik dot org 2008-07-15 01:19
---
Created an attachment (id=15909)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15909action=view)
Patch against 4.3.1 using a once variable to ensure safe initialisation
Here's a patch, let me know what you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21738
--- Comment #2 from Jonathan Larmour jifl-bugzilla at jifvik dot org
2011-04-11 19:59:07 UTC ---
I had forgotten I had submitted this :-). Some work has been done by Richard
Sandiford to address this, and there is now a -mno-extern-sdata option
--- Comment #23 from jifl-bugzilla at jifvik dot org 2010-07-24 22:23
---
I can confirm this fails with GCC 4.4.4 and that GCC 4.3.2 works.
--
jifl-bugzilla at jifvik dot org changed:
What|Removed |Added
--- Comment #32 from jifl-bugzilla at jifvik dot org 2010-09-01 11:47
---
I don't know if there are plans for more releases in the 4.4 series, but can it
be applied to the 4.4 branch too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44328
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jifl-bugzilla at jifvik dot org
Created attachment 34226
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34226action=edit
Main testcase source file to reproduce problem
I submitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64233
--- Comment #1 from Jonathan Larmour jifl-bugzilla at jifvik dot org ---
Created attachment 34227
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34227action=edit
h2.c source code used to support build of h1.c testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64233
--- Comment #2 from Jonathan Larmour jifl-bugzilla at jifvik dot org ---
Created attachment 34228
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34228action=edit
Annotated partial disassembly of main() in testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #7 from Jonathan Larmour jifl-bugzilla at jifvik dot org ---
I have also now submitted bug 64233 which is about a different testcase which
also gets misoptimised. This may or may not be related, but could well be since
-fschedule
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #1 from Jonathan Larmour ---
Created attachment 45617
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45617=edit
Assembler file generated by GCC when compiled with -Os
: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: jifl-bugzilla at jifvik dot org
Target Milestone: ---
Created attachment 45616
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45616=edit
C file to demonstr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #3 from Jonathan Larmour ---
Thanks for the quick reply.
(In reply to Jakub Jelinek from comment #2)
> Not confirming since it is unclear even on what OS you are using this
It's an embedded OS, so from your point of view, it's
: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jifl-bugzilla at jifvik dot org
Target Milestone: ---
Long-standing behaviour is that if you don't want to link against the behemoth
of full libstdc++, but are still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89222
--- Comment #6 from Jonathan Larmour ---
Just to confirm with concrete values from a real program:
myhandler2() is at 0x23a8 (which means the branch target address if the
function is called should be 0x23a9 with LS bit set to indicate
42 matches
Mail list logo
