--- Comment #3 from ramana at gcc dot gnu dot org 2009-03-27 17:12 ---
I can see this with trunk as well as 4.3 branch today.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-03-28 00:05 ---
Since 4.4 is close to being our current release branch, it would be helpful if
you could provide a testcase where you spot the ICE . It would be useful to
have a preprocessed file to see why the ICE is occurring
--- Comment #5 from ramana at gcc dot gnu dot org 2009-03-30 17:11 ---
Assigning to self.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-03-30 18:10 ---
Confirmed. The compiler could generate a
mov sp, r3 instead and the code would be right.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ramana at gcc dot gnu dot org 2009-03-30 18:35 ---
A run through the debugger shows it to be the same as #37436. A backport of the
patch for #37436 fixes the ICE. Bootstrap and regression test under way. Hence
marking this as a duplicate of the same and reopening
--- Comment #7 from ramana at gcc dot gnu dot org 2009-03-30 18:35 ---
*** Bug 36415 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ramana at gcc dot gnu dot org 2009-03-30 18:36 ---
This still exists for the 4.3 branch. Hence reopening.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ramana at gcc dot gnu dot org 2009-03-30 21:24 ---
This is now fixed with the fix for PR35964 which was a backport of the patch
mentioned in comment #5
*** This bug has been marked as a duplicate of 36964 ***
--
ramana at gcc dot gnu dot org changed
--- Comment #2 from ramana at gcc dot gnu dot org 2009-03-30 21:24 ---
*** Bug 36350 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from ramana at gcc dot gnu dot org 2009-03-30 21:25 ---
Reopened because of a typo in the closing comment.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ramana at gcc dot gnu dot org 2009-03-30 21:25 ---
It's a dup of 35964
*** This bug has been marked as a duplicate of 35964 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from ramana at gcc dot gnu dot org 2009-03-30 21:25 ---
*** Bug 36350 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from ramana at gcc dot gnu dot org 2009-03-30 21:27 ---
The commit http://gcc.gnu.org/viewcvs?view=revrevision=143942 fixed this.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from ramana at gcc dot gnu dot org 2009-03-31 15:11 ---
The driver will not pass the mthumb option to the assembler. The documentation
has been updated with the below mentioned commit to handle this case.
http://gcc.gnu.org/viewcvs?view=revrevision=145347
Hence
--- Comment #5 from ramana at gcc dot gnu dot org 2009-03-31 21:51 ---
-frtl-abstract-sequences has been removed with revision id 145374. Hence
marking this as WONTFIX.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ramana at gcc dot gnu dot org 2009-04-02 18:27 ---
Appears to be fixed on trunk, 4.3 and 4.4 branch.
Using built-in specs.
Target: armv5tel-unknown-linux-gnueabi
Configured with: /home/ramana/cos/gcc-4_3-branch/configure
--enable-languages=c,c++
Thread model
--- Comment #11 from ramana at gcc dot gnu dot org 2009-04-03 23:26 ---
Taking this up.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo
--- Comment #12 from ramana at gcc dot gnu dot org 2009-04-09 11:31 ---
For the record here's some more info on the problem.
One part of the problem is as described in comment #1 about labels having the
right bit and the correct instruction being generated which I've achieved
--- Comment #13 from ramana at gcc dot gnu dot org 2009-04-17 11:07 ---
Created an attachment (id=17650)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17650action=view)
Patch being tested
Here is a rather hackish patch that I'm testing. It looks correct so far with
the case
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-17 16:41 ---
As per comment above appears fixed in all release branches today.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-19 11:37 ---
Patch submitted here.
http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01406.html
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-19 21:32 ---
Still occurs with trunk today.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-19 21:41 ---
This appears to be fixed on all release branches. This probably should now be
closed.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35141
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-19 21:59 ---
I believe this is a case of wrong usage of the compiler and this bug could be
closed as invalid. However the question remains about big endian and little
endian compiler options and supporting or not support armeb
--- Comment #7 from ramana at gcc dot gnu dot org 2009-04-19 22:02 ---
This doesn't appear with any of the release branches (4.3, 4.4) or trunk
currently. Can this now be closed out ?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32101
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-20 05:58 ---
The build is broken currently for arm-none-eabi targets on trunk.
Attempting a simple fix of supporting arm-eabi* got me past the error reported
in the original bug report. but I still get a failure
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-20 14:30 ---
Hi Andrew,
I'm not quite sure what you're trying to do.
What did you change to support arm-eabi* ?
I changed libjava/configure.host to also support arm-eabi
(arm*-elf|arm*-eabi)but that probably wasn't
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-20 15:38 ---
Confirmed with gcc version 4.5.0 20090416 (experimental) [trunk revision
146149] (GCC)
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-20 15:44 ---
arm-coff is obsolete with trunk. Can this now be closed out?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from ramana at gcc dot gnu dot org 2009-04-20 23:09 ---
Waiting for feedback if this can be reproduced on a more modern toolchain. I
can't reproduce this with trunk today.
--
ramana at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-21 13:52 ---
(In reply to comment #1)
Created an attachment (id=14957)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14957action=view) [edit]
Patch to fix interrupt handling on entry/exit for ARM
The arm backend already
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-21 14:09 ---
Confirmed with trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-21 14:28 ---
LINUX_DYNAMIC_LINKER et al are defined in gcc/config/linux.h and the correct
definition must reach this case. Looking at the config parameters for --host
and --build , I can spot a typo of linuc-gnu instead of linux
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-21 14:29 ---
Mine.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-21 14:41 ---
This is now fixed as per the last comment.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-21 14:42 ---
confirmed.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-24 09:05 ---
(In reply to comment #2)
Does this mean the target arm-none-uclinux is unsupported?
I checked again, using (binutils-2.17 and) gcc-4.3.3 from mirror site
ftp://ftp.gwdg.de/pub/misc/gcc/releases/gcc-4.3.3/gcc
--- Comment #7 from ramana at gcc dot gnu dot org 2009-04-24 16:00 ---
(In reply to comment #6)
The reason why this happens is because FUNCTION_BOUNDARY is defined as just 32
for both arm and thumb mode.
FUNCTION_BOUNDARY should be 32 for ARM mode and 16 for Thumb mode as defined
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-29 13:48 ---
4.2.x is now closed. Since this appears to work on 4.3.1, could you confirm if
this is still a problem with an eabi toolchain of more recent vintage ?
--
ramana at gcc dot gnu dot org changed:
What
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-29 13:58 ---
Could you check with a version of more recent vintage and provide more
information like the svn revision number ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-29 14:38 ---
The new code has a value of max_idx of DTOR_END - DTOR_LIST - 1. You might want
to see why your implementation has a value of max_idx 1. It doesn't appear to
be a target bug yet - Please check this and get back
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-29 15:50 ---
The size regression occurs with 4.3.x but with trunk today I see a size
reduction to 992 bytes which is in the ball park of the original size.
--
ramana at gcc dot gnu dot org changed:
What
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-29 15:53 ---
This is a duplicate of #37436
*** This bug has been marked as a duplicate of 37436 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-29 15:53 ---
*** Bug 36920 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-29 16:09 ---
Needs a documentation tweak for all the extra bits in the inline assembler for
printing operands.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-29 16:14 ---
Can this be reproduced under a more recent version of the compiler. ? I haven't
been able to reproduce this today on trunk. Waiting for feedback.
--
ramana at gcc dot gnu dot org changed:
What
--- Comment #6 from ramana at gcc dot gnu dot org 2009-04-29 16:22 ---
Is the csl-arm-branch still alive ? Can we clear this one up otherwise?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21751
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-29 16:35 ---
This was fixed with the check for arm32 in the testsuite. This is fixed in
4.4.0.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-29 16:44 ---
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.
--
ramana at gcc dot gnu dot org
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-29 16:50 ---
This appears today with trunk and eabi at r146638.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ramana at gcc dot gnu dot org 2009-04-29 17:19 ---
Can you attach a proper testcase ? It's showing some junk with something called
smime.p7s.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-29 17:30 ---
Need more information on this bug as specified in comment #2
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-29 17:34 ---
gcc 4.3 appears to have support for the cortex-a8 processor and armv7-a. This
could be backported on to the 4.3 branch.
--
ramana at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-29 17:37 ---
(In reply to comment #3)
By compile doxygen, came this error:
g++ -c -pipe -fno-exceptions -fno-rtti -Wall -W -fno-exceptions -O2
-I../qtools
-I../libpng -I../libmd5 -o ../objects/doxygen.o doxygen.cpp
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|c |tree-optimization
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 09:02 ---
Can you try with a later version of the compiler (in the set of released
versions) 4.3.4 , 4.4.0 or trunk and report back ?
Don't get this failure with arm-eabi configurations.
--
ramana at gcc dot gnu dot org
--- Comment #8 from ramana at gcc dot gnu dot org 2009-04-30 10:05 ---
Subject: Bug 38571
Author: ramana
Date: Thu Apr 30 10:04:52 2009
New Revision: 147000
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=147000
Log:
Fix PR target/38571
Modified:
trunk/gcc/ChangeLog
trunk
--- Comment #9 from ramana at gcc dot gnu dot org 2009-04-30 10:05 ---
This is now fixed with r147000
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38571
--- Comment #1 from ramana at gcc dot gnu dot org 2009-04-30 10:10 ---
Can you try with a compiler of more recent vintage and report back.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ramana at gcc dot gnu dot org 2009-04-30 10:18 ---
Can you try with a compiler of more recent vintage and report back ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana at gcc dot gnu dot org
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39975
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 10:25 ---
If there is a request to support a big endian default configuration for ARM,
there should be a separate enhancement request for that. Given this, I'd close
this bug as being invalid. I've filed PR39975
--- Comment #4 from ramana at gcc dot gnu dot org 2009-04-30 10:30 ---
Not sure if this is related to PR31849 as well.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-30 10:39 ---
We need more information on what the exact problem is with the code generated.
Could you try with a compiler of more recent vintage and report back ?
--
ramana at gcc dot gnu dot org changed:
What
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #3 from ramana at gcc dot gnu dot org 2009-04-30 09:27 ---
Seems to work today on gcc50 with gcc 4.4.0 and trunk on the simulator .I don't
see these failures in recent testresults on gcc-testresults@ from the
auto-tester at gcc50.
--
ramana at gcc dot gnu dot org changed
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target
--- Comment #2 from ramana at gcc dot gnu dot org 2009-04-30 11:29 ---
gcc 3.4 is no longer supported. Marking this as WONTFIX.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-01 08:39 ---
*** Bug 39989 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-01 08:39 ---
Marking as duplicate of PR38570
*** This bug has been marked as a duplicate of 38570 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-01 14:49 ---
I don't see this with a bootstrap that I was doing with r147003.
/home/ramana/build-combined-arm-gcc-20090430/./gcc/xgcc -v
Using built-in specs.
Target: armv5tel-unknown-linux-gnueabi
Configured with: ../trunk
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-06 08:46 ---
Can't replicate this with a stage2 or stage3 compiler with O2, O3, Os -fPIC
{-mthumb} with r147121.
However while bootstrapping the above mentioned revision, I get a segfault as
in http://gcc.gnu.org/bugzilla
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-06 10:52 ---
*** This bug has been marked as a duplicate of 16350 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #23 from ramana at gcc dot gnu dot org 2009-05-06 10:52 ---
*** Bug 39975 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-06 10:59 ---
(In reply to comment #1)
What's the ICE?
With a cross arm-linux-gnueabi version r147153, I get a segfault with the
following backtrace for this particular testcase.
#0 0x082112b1 in emit_insn_after_1 (first
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 08:10 ---
*** This bug has been marked as a duplicate of 40031 ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ramana at gcc dot gnu dot org 2009-05-07 08:10 ---
*** Bug 40053 has been marked as a duplicate of this bug. ***
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 11:37 ---
Can you try with a later compiler which is in the release train now and get
back ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-07 11:39 ---
Can you try with a later compiler ? 4.2.x no longer exists. As long as your
headers were fine I don't see why this shouldn't have built.
--
ramana at gcc dot gnu dot org changed:
What|Removed
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-12 09:36 ---
Confirmed with r147377
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-12 10:05 ---
init_expr_once is now renamed to init_expr_target, though I see that the
comments / code you refer to in the bug report still exist . Can you give any
examples of optimizations that might be enabled if we went ahead
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-13 09:52 ---
Can you try a newer version of the compiler ? 4.1.x is unsupported today.
I can see this is fixed on trunk and 4.3 as of revisions 147467 147441. An
older version of 4.4 does not show this problem.
--
ramana
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 10:08 ---
I can see this with trunk at r147467
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-13 10:10 ---
Appears on trunk as of r147467.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 10:14 ---
Can you check this with a later compiler. 4.2.x is closed. Works for me with
current trunk.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from ramana at gcc dot gnu dot org 2009-05-13 10:52 ---
I see a problem with your testcase here. r is assigned to h which has not been
initialized if I uncomment the line //r=h as per your comment above.
int test_func(void *p) {
dummy_func();
register
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 12:31 ---
This appears to be fixed with trunk as of r147467. Can you reproduce this with
4.3 or 4.4 ? If not we can close this one out.
_Z18serial_IRQ_Routinev:
@ Interrupt Service Routine.
@ args = 0, pretend
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 12:34 ---
Appears with today's trunk (r147467) with the following options.
/home/ramrad01/fsfbugzilla/pr36966.c: In function 'foo':
/home/ramrad01/fsfbugzilla/pr36966.c:5: internal compiler error: in
arm_expand_binop_builtin
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-13 12:45 ---
I get an ICE with trunk as of r146467 using -flax-vector-conversions otherwise
the test doesn't compile.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-13 14:33 ---
(In reply to comment #4)
(In reply to comment #3)
(In reply to comment #2)
Also IV-opts is messing up anyways, it should have done out+1 as the base
instead of out, blah.
Filed as http://gcc.gnu.org
--- Comment #2 from ramana at gcc dot gnu dot org 2009-05-13 14:39 ---
I don't see these failing with trunk as of 147209 or on an
arm-none-linux-gnueabi 4.4.x on the testresults mailing list. Do these still
fail for your tester?
--
ramana at gcc dot gnu dot org changed
--- Comment #5 from ramana at gcc dot gnu dot org 2009-05-13 14:51 ---
(In reply to comment #1)
That's what dg-require-profiling does.
IMHO this is a deficiency in your glibc. It's very hard to distinguish between
something is subtly busted and my glibc sucks, so I'm not sure
--- Comment #3 from ramana at gcc dot gnu dot org 2009-05-13 16:34 ---
Can you try a later compiler ?
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #7 from ramana at gcc dot gnu dot org 2009-05-13 23:56 ---
Marking as WONTFIX as per comment#1 above.
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 531 matches
Mail list logo
