--- Comment #10 from ktietz at gcc dot gnu dot org 2010-03-08 08:03 ---
(In reply to comment #9)
Kai,
Patch in Comment #8 is OK to commit. Thanks!
(I also regression tested on x86-64-linux-gnu.)
Ok, applied at revision 157271.
Patch for enumerators ERROR, WARNING, SILENT will
foo1:
stmfd sp!, {r4, r5, r6, lr}
ldr r4, .L2
sub r6, r0, #16 // A
mov r5, r0 // B
mov r3, r1
mov r1, r0
ldr r0, .L2+4
.LPIC0:
add r4, pc, r4
sub sp, sp, #8
mov r2, r6
--- Comment #1 from carrot at google dot com 2010-03-08 08:28 ---
Created an attachment (id=20040)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20040action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
--- Comment #2 from carrot at google dot com 2010-03-08 08:32 ---
The command line options are: -march=armv7-a -O2 -fpic
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43286
--
krebbel at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |krebbel at gcc dot gnu dot
|dot org
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2010-03-08 09:20
---
Created an attachment (id=20041)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20041action=view)
Tentative patch
Tested only on Linux.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43276
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-08 09:35 ---
Subject: Bug 43256
Author: janus
Date: Mon Mar 8 09:35:04 2010
New Revision: 157272
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157272
Log:
2010-03-08 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-08 09:37 ---
Fixed with r157272. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from redi at gcc dot gnu dot org 2010-03-08 10:33 ---
The docs for typeof say A typeof-construct can be used anywhere a typedef name
could be used. That implies it should work in a nested-name-specifier.
However, the typeof behaviour is consistent with decltype, and the
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-03-08 10:39 ---
(In reply to comment #2)
Hm? How does calling std::pow with different types behave differently? The
value can be stored fine if one does double dValue = std::pow(2.0, 64);long
long llValue = dValue; // OK
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-03-08 10:40 ---
Patch welcome (either skipping the test or adjusting the asm)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from jamborm at gcc dot gnu dot org 2010-03-08 10:44
---
I came to the conclusion the patch was indeed a good fix. I have
submitted it to the mailing list along with an explanation of what is
going on: http://gcc.gnu.org/ml/gcc-patches/2010-03/msg00270.html
--
At revision 157266 bootstrap fails at stage 1 on powerpc-apple-darwin9:
/opt/gcc/darwin_buildw/./gcc/xgcc -B/opt/gcc/darwin_buildw/./gcc/
-B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/bin/
-B/opt/gcc/gcc4.5w/powerpc-apple-darwin9/lib/ -isystem
/opt/gcc/gcc4.5w/powerpc-apple-darwin9/include -isystem
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-08 11:08 ---
Created an attachment (id=20042)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20042action=view)
file libgcc2.i
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-08 11:13 ---
Can you provide backtrace where it SIGBUSes?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287
--
jamborm at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot
|dot org
--- Comment #3 from dominiq at lps dot ens dot fr 2010-03-08 11:17 ---
Can you provide backtrace where it SIGBUSes?
I tried with a breakpoint in gdb for fancy_abort, but only got
../../../../gcc-4.5-work/libgcc/../gcc/libgcc2.c:1526:1: internal compiler
error: Bus error
Please submit
--- Comment #17 from jakub at gcc dot gnu dot org 2010-03-08 11:46 ---
Subject: Bug 42233
Author: jakub
Date: Mon Mar 8 11:46:28 2010
New Revision: 157274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157274
Log:
PR middle-end/42233
* dojump.c (do_jump) case
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-08 11:46 ---
Subject: Bug 43121
Author: jakub
Date: Mon Mar 8 11:46:28 2010
New Revision: 157274
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157274
Log:
PR middle-end/42233
* dojump.c (do_jump) case
--- Comment #22 from rguenth at gcc dot gnu dot org 2010-03-08 11:48
---
All is bad again after the fix for PR42220:
2010-03-07 Bernd Schmidt bernd.schm...@analog.com
PR rtl-optimization/42220
* regrename.c (scan_rtx) case STRICT_LOW_PART, ZERO_EXTRACT:
Use
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-08 11:50 ---
That seems like you've tried to debug xgcc instead of cc1. Of course the
backtrace from cc1 is interesting, not from xgcc (which doesn't SIGBUS).
Run xgcc with additional -v option, and copypaste the cc1 command line
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-08 11:54 ---
Subject: Bug 43248
Author: jakub
Date: Mon Mar 8 11:54:11 2010
New Revision: 157275
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157275
Log:
Backport from mainline:
2010-03-04 Andrew Pinski
--- Comment #35 from rguenth at gcc dot gnu dot org 2010-03-08 11:56
---
I find this bug mildly confusing. As the bootstrap / ada issues are fixed
(are they?) I'll split out static int a __attribute__((common)) ICE to separate
PR.
Please close this bug if the bootstra / ada issues
static int a __attribute__((common));
ICEs like
./cc1 -quiet t.i
t.i:32:1: internal compiler error: in function_and_variable_visibility, at
ipa.c:415
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
but instead should
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-08 11:58 ---
I've backported it to 4.4 after bootstrapping/regtesting on x86_64-linux and
i686-linux.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #36 from rguenth at gcc dot gnu dot org 2010-03-08 11:59
---
(In reply to comment #35)
I find this bug mildly confusing. As the bootstrap / ada issues are fixed
(are they?) I'll split out static int a __attribute__((common)) ICE to
separate
PR.
- PR43288
--
--- Comment #18 from jakub at gcc dot gnu dot org 2010-03-08 11:59 ---
Fixed for 4.4.3 too. Don't plan to backport this to 4.3.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2010-03-08 12:03
---
The original bug is fixed.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Fortran 2003 (corrigendum 5, ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1815.pdf)
has now:
Subclause 12.6
Following constraint C1271, add the following new constraint:
C1271a The designator of a variable with the VOLATILE attribute shall not
appear in a pure subprogram.
A designator is a
--- Comment #6 from redi at gcc dot gnu dot org 2010-03-08 12:41 ---
You don't need a new warning to get what you want, as long as you put your
functions in a namespace:
// foo.h
namespace ns {
void myfunc(const char*);
}
// foo.cpp
void ns::myfunc(const char* arg1)
{
/* do
--- Comment #5 from dominiq at lps dot ens dot fr 2010-03-08 12:45 ---
(gdb) run -fpreprocessed libgcc2.i -feliminate-unused-debug-symbols -fPIC
-quiet -dumpbase libgcc2.c -m64 -mmacosx-version-min=10.4 -auxbase-strip
_floatdisf.o -g -O2 -W -Wall -Wwrite-strings -Wcast-qual
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-03-08 13:30 ---
Subject: Bug 43269
Author: rguenth
Date: Mon Mar 8 13:30:27 2010
New Revision: 157276
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157276
Log:
2010-03-08 Richard Guenther rguent...@suse.de
PR
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-08
14:00 ---
Subject: Re: ld: Unsatisfied symbol start in file c_lto_20091216-1_0.o
Patch welcome (either skipping the test or adjusting the asm)
Testing a patch with adjusted asm (uses __hpux).
Dave
--
--- Comment #6 from howarth at nitro dot med dot uc dot edu 2010-03-08
14:08 ---
i686-apple-darwin10 built fine at 157264 and 157265/156266 are commits to the
melt-branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2010-03-08
14:08 ---
Subject: Re: [4.5 Regression] lto-elf.c:388:10: error: 'EM_SPARC'
Created an attachment (id=20041)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20041action=view)
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-03-08 14:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #9 from bangerth at gmail dot com 2010-03-08 14:29 ---
*** Bug 43285 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
--- Comment #2 from bangerth at gmail dot com 2010-03-08 14:29 ---
*** This bug has been marked as a duplicate of 6709 ***
--
bangerth at gmail dot com changed:
What|Removed |Added
--- Comment #10 from redi at gcc dot gnu dot org 2010-03-08 14:40 ---
(In reply to comment #8)
Hmm, I wonder what the current draft of C++0x says of decltype with this
respect (right now we reject it).
In Bug 43285 Comment 1 I said that I think decltype is invalid in this context,
I have only reproducer for this on redhat/gcc-4_4-branch, though I believe the
problem is just latent on vanilla 4.4 branch and likely on the trunk too,
therefore I want to discuss this here.
namespace std
{
template class struct char_traits;
}
typedef struct { union { char __wchb[4]; }; }
--- Comment #11 from redi at gcc dot gnu dot org 2010-03-08 14:46 ---
(In reply to comment #4)
Just noticed this bug myself. You can work around it by creating
a temporary typedef. E.g.,
typedef typeof(obj) T;
T::size_type s;
Still annoying though.
This workaround is
--- Comment #17 from dominiq at lps dot ens dot fr 2010-03-08 14:57 ---
At revision 157277, I no longer see the ICE, but a bunch of errors:
pr42769.f90:5063.10:
res = a%a%csnmi()
1
Error: Type mismatch in argument 'a' at (1); passed
CLASS(psb_d_base_sparse_mat) to
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-08 15:03 ---
Can you make it to fail on trunk or 4.4 branch since it
could be caused by other changes on redhat/gcc-4_4-branch?
If not, can you find out which change on redhat/gcc-4_4-branch
causes this?
--
--- Comment #2 from jakub at gcc dot gnu dot org 2010-03-08 15:12 ---
I've tried, but haven't succeeded, that's why I said the bug is latent there.
If we can prove this situation can't ever happen on 4.4 or 4.5 (4.5 on this
testcase doesn't use a drap reg at all, so we'd need some
--- Comment #3 from hjl dot tools at gmail dot com 2010-03-08 15:27 ---
(In reply to comment #2)
I've tried, but haven't succeeded, that's why I said the bug is latent there.
If we can prove this situation can't ever happen on 4.4 or 4.5 (4.5 on this
testcase doesn't use a drap reg
--- Comment #10 from eric dot weddington at atmel dot com 2010-03-08 15:36
---
(In reply to comment #9)
(In reply to comment #5)
Correction : The bug passes with 4.4.2 and above versions.
Closed as FIXED.
--
eric dot weddington at atmel dot com changed:
What
--- Comment #3 from igodard at pacbell dot net 2010-03-08 15:37 ---
You sure that you want to ban this? Looks like you'll just have to unban it
again. From http://en.wikipedia.org/wiki/Decltype:
In December 2008, a concern was raised to the committee by Jaakko Järvi over
the inability
--- Comment #18 from janus at gcc dot gnu dot org 2010-03-08 15:43 ---
(In reply to comment #17)
At revision 157277, I no longer see the ICE, but a bunch of errors:
pr42769.f90:5063.10:
res = a%a%csnmi()
1
Error: Type mismatch in argument 'a' at (1); passed
--- Comment #4 from jakub at gcc dot gnu dot org 2010-03-08 15:44 ---
Ah, the %ebp saved in DW_OP_reg5 is just a 4.4 bug, fixed by
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00235.html (the fix is in 4.5 and
4.4-RH). Saying that %ebp is saved in DW_OP_breg5 0 is correct and
--- Comment #5 from hjl dot tools at gmail dot com 2010-03-08 15:47 ---
(In reply to comment #4)
Ah, the %ebp saved in DW_OP_reg5 is just a 4.4 bug, fixed by
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00235.html (the fix is in 4.5 and
4.4-RH). Saying that %ebp is saved in
This is a spin-off from PR42769 comment #17. The test case has been extracted
from comment #1 in that PR. It was working before r157272 (which fixed
PR43256), but fails now:
module m1
type :: t1
contains
procedure :: sizeof
end type
contains
integer function sizeof(a)
class(t1)
--- Comment #19 from dominiq at lps dot ens dot fr 2010-03-08 15:49 ---
(In reply to comment #18)
This is surely due to the patch for PR43256 that I committed today.
Sure!
Note that this only happens for comment #1, but not for
comment #8, which still gives the same error as
--- Comment #20 from janus at gcc dot gnu dot org 2010-03-08 15:50 ---
(In reply to comment #18)
I will open a new PR for this.
This is now PR 43291.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-03-08 15:53 ---
Works for me, thus is ok for trunk with a changelog entry.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-08 15:57 ---
As noted in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256#c9, the third
hunk of the patch for resolve.c in revision 157272 does not apply to
fortran-dev. The test in comment #0 passes with fortran-dev and my
--- Comment #4 from manu at gcc dot gnu dot org 2010-03-08 15:59 ---
(In reply to comment #3)
You sure that you want to ban this? Looks like you'll just have to unban it
again. From http://en.wikipedia.org/wiki/Decltype:
This information is nice and welcome but doesn't make this bug
--- Comment #12 from manu at gcc dot gnu dot org 2010-03-08 15:59 ---
*** Bug 43285 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6709
expr.c:expand_expr_real_1
case TARGET_MEM_REF:
{
addr_space_t as = TYPE_ADDR_SPACE (TREE_TYPE (exp));
struct mem_address addr;
doesn't make sense. TREE_TYPE (exp) is the type of the access, not
the pointer-type used for it.
--
Summary: Bogus
--- Comment #7 from erh+gcc at nimenees dot com 2010-03-08 16:07 ---
(In reply to comment #5)
What I'm saying is that this entire discussion is already present in PR13687
and that there is nothing more to say. The warning exists in C because it
can lead to hard-to-find bugs in C code
--- Comment #13 from redi at gcc dot gnu dot org 2010-03-08 16:10 ---
the decltype issue is
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#743
the proposed change is in
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3031.pdf
suspending ...
--
redi at gcc dot
--- Comment #1 from uweigand at gcc dot gnu dot org 2010-03-08 16:11
---
Why doesn't this make sense? The address space is a property of the pointed-to
type, not the pointer type itself (just like const/volatile-ness) ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43292
--- Comment #8 from redi at gcc dot gnu dot org 2010-03-08 16:18 ---
(In reply to comment #7)
That's exactly my point! This is a case where the (function implementation)
code DOES compile cleanly, but there is an obvious problem that causes it to
be
unusable.
See comment 6
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org
|dot org
--- Comment #9 from bangerth at gmail dot com 2010-03-08 16:23 ---
(In reply to comment #7)
The code that calls the function also *compiles* cleanly, and only the link
fails.
By compiling I meant translating from source code to executable. That
includes linking. The point I want to
--- Comment #1 from hjl dot tools at gmail dot com 2010-03-08 16:32 ---
It is caused by revision 154121:
http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00342.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43288
--- Comment #10 from erh+gcc at nimenees dot com 2010-03-08 16:35 ---
(In reply to comment #8)
The code that calls the function also *compiles* cleanly, and only the link
fails.
No, the code calling it does not compile cleanly if there's no previous
declaration.
It only
--- Comment #11 from erh+gcc at nimenees dot com 2010-03-08 16:36 ---
(In reply to comment #6)
You don't need a new warning to get what you want, as long as you put your
functions in a namespace:
...snip...
error: 'void ns::myfunc(const char*)' should have been declared inside 'ns'
--- Comment #6 from jakub at gcc dot gnu dot org 2010-03-08 16:38 ---
Not sure if there haven't been follow-ups. There were at least 100 changes to
dwarf2out.c since 4.4 release, and at least 10 of them were related to the
indirect vs. direct stuff.
--
--- Comment #7 from jakub at gcc dot gnu dot org 2010-03-08 16:39 ---
Created an attachment (id=20043)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20043action=view)
gcc44-pr43290-1.patch
One alternative fix that cures this testcase on redhat/gcc-4_4-branch.
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-03-08 16:42 ---
Oh, it is. Sorry for the noise.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-08 16:45 ---
Created an attachment (id=20044)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20044action=view)
gcc44-pr43290-2.patch
Another fix. Wonder why that insn is marked as frame related at all, for the
drap saving
--- Comment #9 from hjl dot tools at gmail dot com 2010-03-08 16:58 ---
(In reply to comment #8)
Created an attachment (id=20044)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20044action=view) [edit]
gcc44-pr43290-2.patch
Another fix. Wonder why that insn is marked as frame
int i;
static int j;
extern int bar (void);
int foo (void)
{
return i + j + bar ();
}
-m32 -O2 -fpic -mtune=generic -fexceptions generates:
.cfi_startproc
pushl %ebp
.cfi_def_cfa_offset 8
movl%esp, %ebp
.cfi_offset 5, -8
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-08 17:00 ---
I'll test it, both on the trunk and 4.4-RH.
BTW, I've moved the 2) issue to PR43293.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from redi at gcc dot gnu dot org 2010-03-08 17:02 ---
(In reply to comment #11)
hmm... is there a way to have g++ put everything into some default namespace
so
I always get errors like this? If so, that would satisfy my needs.
No.
--
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-08 17:15 ---
No longer working on this one.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from pinskia at gcc dot gnu dot org 2010-03-08 17:16
---
No longer working on this one, I lost the patches when I left sony.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from spop at gcc dot gnu dot org 2010-03-08 17:49 ---
Subject: Bug 42326
Author: spop
Date: Mon Mar 8 17:48:55 2010
New Revision: 157280
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157280
Log:
Fix PR42326: handle default definitions.
2010-03-02 Sebastian Pop
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2010-03-08
17:50 ---
regress is failing from this...
http://gcc.gnu.org/regtest/HEAD/native-lastbuild.txt.gzip
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43287
--- Comment #10 from spop at gcc dot gnu dot org 2010-03-08 17:50 ---
Subject: Bug 43065
Author: spop
Date: Mon Mar 8 17:49:48 2010
New Revision: 157288
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157288
Log:
Add testcase from PR43065.
2010-03-04 Sebastian Pop
--- Comment #11 from spop at gcc dot gnu dot org 2010-03-08 17:50 ---
Subject: Bug 43065
Author: spop
Date: Mon Mar 8 17:49:57 2010
New Revision: 157289
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157289
Log:
Fix PR43065: Insert bounds on pointer type parameters.
2010-03-05
--- Comment #20 from spop at gcc dot gnu dot org 2010-03-08 17:51 ---
Fixed now the second unrelated bug reported within this PR.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from spop at gcc dot gnu dot org 2010-03-08 17:53 ---
Fixed.
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #8 from howarth at nitro dot med dot uc dot edu 2010-03-08
17:54 ---
The last good build for powerpc-apple-darwin9 on regress was at r157263 so...
r157264
must be the offending commit. Is powerpc64-unknown-linux-gnu still
bootstrapping?
--
--- Comment #11 from spop at gcc dot gnu dot org 2010-03-08 17:54 ---
Fixed by http://gcc.gnu.org/viewcvs?root=gccview=revrev=157287
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from spop at gcc dot gnu dot org 2010-03-08 17:55 ---
Fixed by http://gcc.gnu.org/viewcvs?view=revisionrevision=157286
--
spop at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from ullner at gmail dot com 2010-03-08 17:59 ---
That still doesn't make sense.
1. Why does enabling -O3 (O1 and O2 does the same) remove this problem?
2. Why does storing the value in an intermediate variable make any change in
what the result is?
Consider without O3:
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-08 18:11 ---
x is:
(unspec:DI [
(symbol_ref/u:DI (*LC0) [flags 0x2])
] 50)
Guess rs6000_delegitimize_address needs to handle UNSPEC_MACHOPIC_OFFSET.
ix86_delegitimize_address handles it, so assuming it means the same
if [ x-fpic != x ]; then \
/home/andreas/src/gcc/m68k/./gcc/xgcc
-B/home/andreas/src/gcc/m68k/./gcc/ -B/usr/local/m68k-linux/m68k-linux/bin/
-B/usr/local/m68k-linux/m68k-linux/lib/ -isystem
/usr/local/m68k-linux/m68k-linux/include -isystem
/usr/local/m68k-linux/m68k-linux/sys-include
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-08 19:08 ---
Created an attachment (id=20045)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20045action=view)
gcc45-pr43287.patch
Possible fix. Needs testing on darwin as well as verification that there
really isn't any
--- Comment #1 from jakub at gcc dot gnu dot org 2010-03-08 19:15 ---
m68k probably needs a delegitimize_address target hook that will transform some
UNSPEC (or expression involving UNSPEC) back to what debuginfo can contain.
See i386, rs6000, s390 etc. hooks.
--
--- Comment #1 from redi at gcc dot gnu dot org 2010-03-08 19:27 ---
compiles without problems using 4.4.3 and 4.5.0
if this only fails with GCC 4.2 it's unlikely to get fixed
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from aldot at gcc dot gnu dot org 2010-03-08 19:28 ---
(In reply to comment #8)
What's the status of this bug ?
we currently still end up with
call 0
on e.g. i386
The same things can happen in libraries with fpic
yes. Thing is that we could theoretically work around
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-03-08 19:30 ---
This was fixed in at least 4.2.4 so closing as fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-03-08 19:49 ---
The regno that is failing is 22 which is xmm1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dominiq at lps dot ens dot fr 2010-03-08 20:06 ---
With the patch in comment #10 I am now at stage 2. So far so good! Thanks for
the patch.
Why is rs6000_delegitimize_address much simpler (even with the patch) than
ix86_delegitimize_address?
--
dominiq at lps
--- Comment #3 from dushistov at mail dot ru 2010-03-08 20:18 ---
(In reply to comment #1)
compiles without problems using 4.4.3 and 4.5.0
if this only fails with GCC 4.2 it's unlikely to get fixed
There is something strange here.
I have report that with little different
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2010-03-08 20:19
---
Regarding the additional test cases given here:
http://gcc.gnu.org/ml/fortran/2010-03/msg00037.html
I do believe that gfortran has this correct. You are not allowed to attempt to
read from a location past the
I just ran the new sourceforge-based tool cppcheck over
the source code of the 4.5 snapshot 20100304 and cppcheck said
[./zlib/contrib/iostream2/zstream.h:101]: (style) The function 'izstream::fp'
can be const
[./zlib/contrib/iostream2/zstream.h:234]: (style) The function 'ozstream::fp'
can be
1 - 100 of 151 matches
Mail list logo
