--- 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
Severity: minor
Priority: P3
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-gn
--- 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=8324&action=view)
Suggested patch to correctly treat -0.0 and subnormals
No problem, here it is.
--
tatus: 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 triplet:
--- 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=8555&action=view)
Preprocessed testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20810
Severity: 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 confirme
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 triplet: i686-pc-linux-gnu
GCC target triplet: m68k-elf
http://gcc.gnu
long long
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
--- 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=16535&action=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
bette
--- 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24025
Jonathan Larmour changed:
What|Removed |Added
CC||jifl-bugzilla at jifvik dot
--- 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
: 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=30966&action=edit
libgcc patch to correct operation with non-interworking thumb builds
I have inc
: 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&action=edit
C file to demo
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&action=edit
Assembler file generated by GCC when compiled with -Os
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 essen
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 Th
: 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
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=34226&action=edit
Main testcase source file to reproduce problem
I su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64233
--- Comment #1 from Jonathan Larmour ---
Created attachment 34227
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34227&action=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 ---
Created attachment 34228
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34228&action=edit
Annotated partial disassembly of main() in testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #7 from Jonathan Larmour ---
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-insns is what makes a difference, an
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 changed:
What|Removed |Added
Known to fail||4.8.3
--- Comment #2 from Jonathan La
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347
--- Comment #4 from Jonathan Larmour ---
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 it with --with-arch=cf. Sorry I should
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21738
--- Comment #2 from Jonathan Larmour
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.
I think this bug now can be abo
--- 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
ering
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
--- 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
#include
int
main(int argc, char *argv[])
{
std::cout << "Hello world" <<
--- 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=15909&action=view)
Patch against 4.3.1 using a once variable to ensure safe initialisation
Here's a patch, let me k
--- 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
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 target triplet: mipsisa32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21738
iority: 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 triplet: i686-pc-linux-gnu
GCC target triplet: m68k-
--- 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=9080&action=view)
Stripped down source file to reproduce problem
Compile with:
m68k-elf-gcc -c -m5200 -O1 -fun
--- 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/curren
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: arm-unknown-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19781
42 matches
Mail list logo
