--- Comment #4 from mikpe at it dot uu dot se 2009-03-20 11:08 ---
(In reply to comment #3)
No feedback in over a year. Presumed fixed in 4.3.0.
I can confirm that this test case works when compiled with a vanilla gcc-4.3.3
built for armv5tel eabi.
--
http://gcc.gnu.org/bugzilla
--- Comment #1 from mikpe at it dot uu dot se 2007-05-31 19:48 ---
I cannot reproduce this on an armv5b-softvfp-linux machine, with either
gcc-3.3.6, gcc-4.0.4, gcc-4.1.2, or gcc-4.2.0 (all bootstrapped natively on the
arm machine).
However, I suspect your test case is wrong. Unpatched
--- Comment #3 from mikpe at it dot uu dot se 2007-05-31 20:01 ---
I can confirm this broken behaviour, including that it disappears if the 'c'
variable is renamed to 'xxc', with gcc-3.3.6, 4.0.4, 4.1.2, and 4.2.0, all
running natively on an armv5b-softvfp-linux machine.
--
mikpe
--- Comment #2 from mikpe at it dot uu dot se 2007-05-31 20:35 ---
I cannot reproduce this bug with gcc-4.0.4, 4.1.2, or 4.2.0 on an
armv5b-softvfp-linux machine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26463
--- Comment #2 from mikpe at it dot uu dot se 2009-04-12 09:11 ---
(In reply to comment #1)
There is no undefined behavior here (increment of a short value converts
to int, increments then converts back to short, none of which are
undefined), so at least the wrong code issue would
--- Comment #4 from mikpe at it dot uu dot se 2009-04-12 21:33 ---
(In reply to comment #3)
(In reply to comment #2)
(In reply to comment #1)
There is no undefined behavior here (increment of a short value converts
to int, increments then converts back to short, none of which
--- Comment #1 from mikpe at it dot uu dot se 2009-04-22 08:05 ---
(In reply to comment #0)
% gcc-snapshot -funsigned-bitfields testsuite/gcc.dg/bitfld-3.c
% ./a.out
Abort
Confirmed with gcc-4.3-20090419 on i686-pc-linux-gnu.
--
mikpe at it dot uu dot se changed
--- Comment #1 from mikpe at it dot uu dot se 2009-05-03 19:39 ---
(In reply to comment #0)
Create a default configuration that honours big endian ARM by default. PR31938
refers to this.
Looks like a dupe of PR16350. And most of the de-facto standard patch people
have been applying
--- Comment #7 from mikpe at it dot uu dot se 2009-05-03 19:53 ---
(In reply to comment #6)
Created an attachment (id=17475)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17475action=view) [edit]
Proposed fix -- will commit after trunk reopens
Ping, trunk is open now, no? I've
--- Comment #4 from mikpe at it dot uu dot se 2009-05-03 20:05 ---
(In reply to comment #3)
Comment #2 indicates that there isn't a problem with a 4.x series compiler .
I'd like some feedback if this problem exists today with a more recent version
of the compiler.
I can't reproduce
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: armv5tel-unknown-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40178
--- Comment #2 from mikpe at it dot uu dot se 2009-05-17 18:01 ---
(In reply to comment #1)
This is essentially the same as PR40133, which is blocked by PR40134.
Agreed. The underlying issue appears to be the static libgcc only symbols. One
wonders why they did things that way
--- Comment #5 from mikpe at it dot uu dot se 2009-05-19 08:24 ---
(In reply to comment #1)
I've been bootstrapping trunk pretty regularly for arm-linux-gnueabi on the
compile farm (though not building with latest libc) and haven't seen such a
problem .
Note that the bug report
--- Comment #8 from mikpe at it dot uu dot se 2009-05-22 19:18 ---
Created an attachment (id=17902)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17902action=view)
always pass -lgcc to linker
The link error reported by Matthias Klose is caused by the following:
1. g++ links shared
failures from PR39791 and PR40061 fixes
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: bootstrap
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
--- Comment #1 from mikpe at it dot uu dot se 2009-05-27 08:26 ---
Created an attachment (id=17921)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17921action=view)
fix alpha compile failure in dwarf2out.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40268
--- Comment #4 from mikpe at it dot uu dot se 2009-05-28 08:40 ---
(In reply to comment #3)
I just tried this with gfortran 4.3.3 that I have on my ubuntu box. I don't
get
a failure with arm-linux-gnueabi. Can you verify that this still exists with
arm-linux configurations
--- Comment #2 from mikpe at it dot uu dot se 2009-05-31 08:10 ---
(In reply to comment #1)
The one compiled with O2 has wrong binary code.
The problem occurs when GCC compiles the following lines with O2 flag.
if (pdw memcmp(a1, a2, pdw 2))
return 0
--- Comment #2 from mikpe at it dot uu dot se 2009-06-04 09:22 ---
(In reply to comment #0)
% gcc-snapshot -funsigned-bitfields testsuite/gcc.dg/bitfld-3.c
% ./a.out
Abort
Confirmed with gcc-4.4-20090602 and gcc-4.3-20090531 on i686-pc-linux-gnu. I
haven't been able to reproduce
--- Comment #13 from mikpe at it dot uu dot se 2009-06-11 00:01 ---
(In reply to comment #11)
Fixed.
Not quite. I'm trying to build gcc-4.4-20090609 on powerpc64-unknown-linux-gnu,
with binutils 2.17.50.0.6-6, configured with --enable-languages=c,ada
--with-cpu=default32 --disable
--- Comment #2 from mikpe at it dot uu dot se 2009-06-11 20:03 ---
(In reply to comment #1)
I've been bitten by this bug, which is almost 2 years old. I haven't tested it
with gcc 4.4 though, but I confirm that it happens with gcc-4.3.3. Is there
anyone willing to correct this?
gcc
--- Comment #4 from mikpe at it dot uu dot se 2009-06-12 20:41 ---
(In reply to comment #3)
Can someone identify the patch that fixed that on the trunk?
I've identified r139702, the fix for PR37005, as the revision which fixed this
test case on gcc-4.4. That change applies easily
--- Comment #2 from mikpe at it dot uu dot se 2009-06-14 10:24 ---
(In reply to comment #1)
With 4.5 I see
With 4.5.0 I see:
push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp
--- Comment #3 from mikpe at it dot uu dot se 2009-06-14 14:06 ---
(In reply to comment #1)
With 4.5 I see
With 4.5.0 I see:
push{lr}
sub sp, sp, #12
ldr r2, [r0]
ldr r1, [r0, #4]
mov r0, sp
str r2, [sp
--- Comment #15 from mikpe at it dot uu dot se 2009-06-15 14:24 ---
(In reply to comment #14)
ping 4.3.4...
The PR40087 fix depends on changes from the PR39455 fix. Both of them are 4.3
regressions, and I've used both fixes in my 4.3 tree for a while now without
issues.
--
http
--- Comment #2 from mikpe at it dot uu dot se 2009-06-16 15:17 ---
(In reply to comment #0)
gcc-m68k-ice.c:28: internal compiler error: in reload_cse_simplify_operands,
at
postreload.c:393
If any of the options -m5307, -msep-data, or -O1 is removed, the problem goes
away
--- Comment #5 from mikpe at it dot uu dot se 2009-06-16 16:29 ---
(In reply to comment #4)
Works with 4.3.1. Should this be closed if someone can confirm it is fixed on
the trunk?
This is a generic m68k issue as I can easily reproduce the ICE using a
gcc-4.2.4 based cross-compiler
--- Comment #2 from mikpe at it dot uu dot se 2009-06-17 14:08 ---
(In reply to comment #1)
Works for 4.4.1 and 4.5.0
ICEs for me with today's 4.4 branch on i686-linux. The -O0 -fstack-protector
combination is key, with -O1 and above it works, ditto without
-fstack-protector
--- Comment #1 from mikpe at it dot uu dot se 2009-06-17 18:51 ---
Dupe of PR40268/PR40061.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40477
at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40547
--- Comment #1 from mikpe at it dot uu dot se 2009-06-24 22:25 ---
Created an attachment (id=18063)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18063action=view)
test case
test case illustrating the bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40547
--- Comment #2 from mikpe at it dot uu dot se 2009-06-24 22:29 ---
Created an attachment (id=18064)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18064action=view)
proposed patch fixing this error
This patch adapts Paolo Bonzini's patch for PR39867 to handle the remaining two
--- Comment #10 from mikpe at it dot uu dot se 2009-06-25 12:12 ---
(In reply to comment #9)
Fixed.
The gcc-4.3 backport or PR32041 to c-parser.c adds an assignment to `loc'. The
mainline version needed that for build_array_ref, but in 4.3 build_array_ref
does not take a loc parameter
--- Comment #9 from mikpe at it dot uu dot se 2009-06-26 19:49 ---
I believe this is the same issue as in PR39254.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38886
--- Comment #7 from mikpe at it dot uu dot se 2009-07-01 10:53 ---
(In reply to comment #6)
Fixed for 4.4.1.
This test case causes the same ICE in tsubst also with gcc-4.3.4.
After packporting the ICE fix, 4.3.4 instead fails with:
variadic94.C: In function 'int main()':
variadic94
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40635
--- Comment #1 from mikpe at it dot uu dot se 2009-07-06 09:32 ---
Ditto here on powerpc64-unknown-linux-gnu. -m32 gives the warning, -m64 does
not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40658
--- Comment #2 from mikpe at it dot uu dot se 2009-07-07 10:18 ---
(In reply to comment #1)
Now I'm trying to compile gcc-4.4.0 configured as follows:
../gcc-4.4.0/configure --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --enable-languages=c
--- Comment #3 from mikpe at it dot uu dot se 2009-07-07 11:35 ---
Confirmed, with gcc-4.3-20090705 it works, with gcc-4.4-20090630 it fails.
Compiling with -S and comparing the .s files it looks like 4.4 completely
mis-schedules the code for put_uint32:
put_uint32:
.register
--- Comment #4 from mikpe at it dot uu dot se 2009-07-07 16:28 ---
A reghunt identified Jakub's (added to cc: list) r142481 (PR38367 fix) as the
source of this regression.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--- Comment #6 from mikpe at it dot uu dot se 2009-07-07 23:10 ---
(In reply to comment #5)
Created an attachment (id=18151)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18151action=view) [edit]
gcc44-pr40668.patch
Untested patch that fixes this testcase.
Thanks. This fixes
--- Comment #6 from mikpe at it dot uu dot se 2009-07-08 09:59 ---
(In reply to comment #2)
Replacing *tbl++ by tbl[i] gives this ARM code:
.L2:
mov r3, #10
str r3, [r2], #4
cmp r2, #0
bne .L2
bx lr
See, gcc knows
--- Comment #7 from mikpe at it dot uu dot se 2009-07-08 16:43 ---
4.4-20090630 plus this fix bootstrapped fine, fixed the test case, built a
working 2.6.31-rc2 Linux kernel, and built a working Erlang VM.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40668
--- Comment #10 from mikpe at it dot uu dot se 2009-07-09 14:45 ---
I've identified Jakub's r140177 (PR37356) as the point where these test cases
were fixed in 4.4.0. A backport doesn't look easy (to me anyway).
--
mikpe at it dot uu dot se changed:
What|Removed
--- Comment #2 from mikpe at it dot uu dot se 2009-07-09 19:03 ---
This was fixed for 4.4.0 by Richard's r143339.
I backported that to 4.3.4 and it built ok and fixed this test case. My boxes
are ARMv5TE so I cannot run the generated thumb2 code however.
--
http://gcc.gnu.org
--- Comment #3 from mikpe at it dot uu dot se 2009-10-17 22:08 ---
I just had a look at some gcc-4.4.2 testsuite failure on arm-linux-gnueabi, and
came across the uninit-13.c one and this PR.
The error is not that uninit-13.c triggers an is used uninitialized warning,
it's supposed
--- Comment #3 from mikpe at it dot uu dot se 2009-10-18 12:55 ---
On ARM, gcc generates assembly code for the bb-reorg.c test case that gas fails
to assemble. The pr34999.c test case fails for the same reason. The following
reduced assembly snippet illustrates it:
cat bb-reorg.s
--- Comment #6 from mikpe at it dot uu dot se 2009-10-18 17:58 ---
Revision 152966 on 4.4 branch causes a testsuite regression for me on
i686-linux:
Running /mnt/builds/gcc-4.4-r152966/gcc/testsuite/g++.dg/dg.exp ...
FAIL: g++.dg/cpp0x/rv-reinterpret.C execution test
Reverting just
--- Comment #23 from mikpe at it dot uu dot se 2009-10-21 10:48 ---
(In reply to comment #8)
(In reply to comment #7)
With binutils from the 2.20 branch, and gcc from the 4.4 branch, including
Jakub's patch, and excluding the current workaround from Ramana, I get:
IIUC
--- Comment #11 from mikpe at it dot uu dot se 2009-10-21 10:51 ---
*** Bug 40547 has been marked as a duplicate of this bug. ***
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--- Comment #3 from mikpe at it dot uu dot se 2009-10-21 10:51 ---
*** This bug has been marked as a duplicate of 40747 ***
--
mikpe at it dot uu dot se changed:
What|Removed |Added
--- Comment #8 from mikpe at it dot uu dot se 2009-10-21 12:19 ---
I can reproduce the misalignment exceptions on armv5tel-linux-gnueabi with
gcc-4.3.4 at -O0 but not with gcc-4.4.2. The loop in main() which iterates
over the packed array creates a misaligned pointer from which
--- Comment #10 from mikpe at it dot uu dot se 2009-10-21 19:47 ---
(In reply to comment #9)
My version is:
[r...@ build]# ccmips -V
ccmips: `-V' option must have argument
[r...@pace build]# ccmips --version
ccmips (GCC) 3.3.2 20030904 (Wind River vxworks61) (built 20050516
--- Comment #11 from mikpe at it dot uu dot se 2009-10-22 17:55 ---
Created an attachment (id=18869)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18869action=view)
reduced test case in plain C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
--- Comment #12 from mikpe at it dot uu dot se 2009-10-23 00:29 ---
The ARM misalignment bug in this PR was fixed for gcc-4.4 by r141742, an
apparently ia64- and Ada-motivated generic patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
--- Comment #13 from mikpe at it dot uu dot se 2009-10-23 12:49 ---
Created an attachment (id=18879)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18879action=view)
backport of r141742 to gcc-4.3.4 that I'm testing
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37954
: mikpe at it dot uu dot se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41809
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41895
--- Comment #5 from mikpe at it dot uu dot se 2009-11-04 15:47 ---
On x86_64 there's a 128 byte area below %rsp which is free to use without first
setting up a stack frame. This is described in the x86_64 ABI document. The
Linux kernel skips this area before pushing signal handler stack
--- Comment #1 from mikpe at it dot uu dot se 2009-11-14 16:09 ---
Presumably fixed for 4.5 by revision 154178.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42044
--- Comment #5 from mikpe at it dot uu dot se 2009-11-14 16:32 ---
This wrong-code bug also occurs with 4.3.4 on i686-linux, but not with 4.2.4 or
4.1.2, making it a regression. The patch for 4.4 applies cleanly to 4.3 and
fixes the bug there with no new regressions (I tested i686
--- Comment #3 from mikpe at it dot uu dot se 2009-12-09 16:07 ---
(In reply to comment #2)
libmpfr must be a shared object because libmpc relies on hidden, global state
in libmpfr. If libmpfr is linked statically with libmpc and with GCC, each
receives different instances
--- Comment #4 from mikpe at it dot uu dot se 2009-12-14 12:57 ---
This bug is also present in gcc-4.4-20091208 but not in gcc-4.3-20091206. The
two fixes listed here apply Ok to 4.4 and solve the problem there w/o
regressions (tested on i686, powerpc64, and arm).
--
mikpe at it dot
--- Comment #7 from mikpe at it dot uu dot se 2009-12-16 21:27 ---
I've done a binary search which identified 154688 as the revision which caused
the problem to appear.
To answer Bernd's question, I used an arm cross configured with:
--target=armv5tel-unknown-linux-gnueabi
--with-gmp
--- Comment #11 from mikpe at it dot uu dot se 2009-12-21 11:55 ---
(In reply to comment #10)
Fixed.
You forgot to add the test case in the 4.4 backport.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
libjava on ARM
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC build triplet: armv5tel
--- Comment #1 from mikpe at it dot uu dot se 2009-12-26 14:59 ---
Reverting r155171 allows gcc-4.4-20091215 to build a working libjava again.
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=155171
Log:
2009-12-11 Ramana Radhakrishnan ramana.radhakrish...@arm.com
PR
--- Comment #5 from mikpe at it dot uu dot se 2009-12-27 13:59 ---
(In reply to comment #4)
Note, however, that something is definitely wrong in the analysis: PR40133 and
PR40134 have been fixed **only in mainline**, thus per se those changes cannot
be involved in a breakage
--- Comment #7 from mikpe at it dot uu dot se 2009-12-28 00:46 ---
(In reply to comment #5)
I believe it's the *absence* of the PR40134 fix on 4_4-branch that's causing
the backport of __sync_synchronize() support to regress. I'm currently testing
4.4-20091215 with relevant bits
--- Comment #10 from mikpe at it dot uu dot se 2009-12-28 12:11 ---
Matthias, your Debian patch includes the following, which is not part of the
trunk fix for PR40134 but instead appears to be a fragment from an early
version of the PR41175/PR40677 fix (which seems to depend on PR40134
--- Comment #12 from mikpe at it dot uu dot se 2009-12-29 13:05 ---
Created an attachment (id=19413)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19413action=view)
pr40134 generic + arm bits
This is the version of the PR40134 patch I intend to submit, unless Matthias
wants
--- Comment #14 from mikpe at it dot uu dot se 2009-12-29 23:15 ---
Patch submitted:
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01192.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42503
--- Comment #7 from mikpe at it dot uu dot se 2009-12-30 16:45 ---
FWIW, Ian's fix backports trivially to 4.4 and 4.3 and fixes this test case
there with no test suite regressions (all default languages) on i686-linux.
--
mikpe at it dot uu dot se changed:
What
--- Comment #1 from mikpe at it dot uu dot se 2009-12-30 22:40 ---
(In reply to comment #0)
I tried to compile gcc (4.4.1 and 4.4.2) for m68k-coff for Linux. I'm
using Ubuntu 9.10 AMD64. However, I get an error stating that gas is not
supported for the version of binutils (2.20) used
--- Comment #2 from mikpe at it dot uu dot se 2009-12-31 00:53 ---
(In reply to comment #0)
When compiling m68k-elf the process went
smoothly and I can install (m68k-elf-as, m68k-elf-ar, etc.). But this
time I can not compile gcc 4.4.1 or 4.4.2 (m68k-elf-gcc) because I
get an error
--- Comment #10 from mikpe at it dot uu dot se 2009-12-31 17:01 ---
Created an attachment (id=19431)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19431action=view)
simpler test case
I'm attaching a reduced test case that triggers wrong-code for m68k-elf with
gcc-4.5-20091224
--- Comment #2 from mikpe at it dot uu dot se 2010-01-01 17:37 ---
Created an attachment (id=19437)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19437action=view)
fix arm eabi default cpu type
Try this patch, from debian. It corrects arm-eabi to choose an
armv4t-compatible
--- Comment #4 from mikpe at it dot uu dot se 2010-01-01 19:48 ---
(In reply to comment #3)
Try this patch, from debian. It corrects arm-eabi to choose an
armv4t-compatible arm9tdmi as the default cpu type. Otherwise it may generate
armv5t code, which is consistent with your illegal
--- Comment #4 from mikpe at it dot uu dot se 2010-01-02 14:21 ---
(In reply to comment #3)
However, the goal is to compile gcc for the coff format and
I'm having it difficulties.
Consider the following two facts:
1. binutils-2.17 removed m68k-coff support, that was 3.5 years ago
2
--- Comment #10 from mikpe at it dot uu dot se 2010-01-03 23:15 ---
(In reply to comment #9)
Fascinating indeed. If someone can bisect where during 4.4 development we
fixed this again or where during 4.3 development we broke it that would be
nice.
This test case was fixed for 4.4
--- Comment #17 from mikpe at it dot uu dot se 2010-01-05 15:41 ---
Fixed now, closing.
--
mikpe at it dot uu dot se changed:
What|Removed |Added
Status|NEW
--- Comment #4 from mikpe at it dot uu dot se 2010-01-10 22:05 ---
(In reply to comment #3)
Works for me with current 4.4 branch and trunk.
I think this patch fixed it -
http://gcc.gnu.org/ml/gcc-patches/2008-05/msg00303.html -
http://gcc.gnu.org/viewcvs?view=revisionrevision
--- Comment #2 from mikpe at it dot uu dot se 2010-01-13 12:14 ---
With a recent gcc-4.4 I see this -O1/-O2 difference on i686 but not powerpc64.
On i686 gcc-4.3 also seems affected (-O0 vs -O1), but 4.2 and 4.1 seem Ok.
--
mikpe at it dot uu dot se changed:
What
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37768
--- Comment #2 from mikpe at it dot uu dot se 2008-10-09 07:04 ---
The program below illustrates the issue. It declares a private C99-compliant
snprintf() implementation and invokes it with %zu and %llx formats. This
triggers the following bogus warnings on x86_64-pc-mingw32
--- Comment #1 from mikpe at it dot uu dot se 2008-10-25 20:55 ---
Same here. gcc-4.4-20081024 configured with --enable-languages=c,c++ and built
using gcc-4.3.2/binutils-2.18.93 on cygwin (XP 64 Pro) ICEs when compiling
type_traits.h. It also ICEs in the same place when configured
--- Comment #2 from mikpe at it dot uu dot se 2008-10-31 10:03 ---
(In reply to comment #1)
I rebuilt my toolchains with binutils-2.19 + three fixes and now
gcc-4.4-20081024 builds fine for me with --enable-languages=c,c++.
The three addon fixes in my binutils-2.19 are:
1. http
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: x86_64-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
--- Comment #1 from mikpe at it dot uu dot se 2008-11-01 18:10 ---
Created an attachment (id=16610)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16610action=view)
patch to unbreak --disable-shared on mingw32
Proposed patch to unbreak --disable-shared on mingw32. When PR37528
--- Comment #3 from mikpe at it dot uu dot se 2008-11-03 13:49 ---
(In reply to comment #2)
Danny, I've tested the revised patch both with and without --disable-shared,
and both configs build and work fine.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37989
--- Comment #2 from mikpe at it dot uu dot se 2008-03-16 16:49 ---
(In reply to comment #1)
This happens with 4.1, 4.2 and trunk on old ABI. Apparently it doesn't
happen with EABI.
I see the problem too, on Linux/ARM/OABI with gcc-4.1.2.
However, the problem is in the test case
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35812
--- Comment #7 from mikpe at it dot uu dot se 2008-05-27 20:48 ---
(In reply to comment #6)
Fixed.
I added the fix to the latest gcc-4.3 snapshot and bootstrapped it.
I then tested both the original application that failed (Erlang)
as well as the latest Linux kernel. Both built
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mikpe at it dot uu dot se
GCC host triplet: i386-pc-solaris2.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36356
--- Comment #6 from mikpe at it dot uu dot se 2008-05-28 13:20 ---
(In reply to comment #5)
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
make[1]: *** [configure-target-libgomp] Error 1
--- Comment #5 from mikpe at it dot uu dot se 2009-07-11 15:23 ---
The bug occurs on OABI with gcc-4.3-20090705 but not with gcc-4.4-20090707.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38642
--- Comment #13 from mikpe at it dot uu dot se 2009-07-11 15:34 ---
(In reply to comment #12)
would be interesting to know what fixed this on the trunk.
A binary search on trunk identified revision 138207 as the point that fixed
this ICE. That revision is a large merge from gimple
--- Comment #3 from mikpe at it dot uu dot se 2009-07-11 20:20 ---
It seems that cpu type and tuning options make a difference here. If I compile
with -mcpu and -mtune referring to a cpu that does not imply FL_LDSCHED, such
as arm740t, then I get the broken code that clobbers r0 before
--- Comment #4 from mikpe at it dot uu dot se 2009-07-12 11:29 ---
Created an attachment (id=18179)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18179action=view)
reduced test case in plain C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39429
--- Comment #6 from mikpe at it dot uu dot se 2009-07-12 21:21 ---
(In reply to comment #5)
What options did you use ? Did you use -O2 , -O3 or -Os with the testcase
you've added here ? I don't see the problem with 4.5.0 trunk 149479 with
either
-mcpu=arm740t or with arm7tdmi
1 - 100 of 422 matches
Mail list logo
