As I have no window overflow trap handler the space reserved on the
stack for saving in and local registers is just wasted memory. Is there
any way I can reclaim this space by forcing the compiler to not honour
the standard SPARC ABI?
No, there isn't, unless you want to hack the compiler.
Chandra Prakash Garg chandra.prak...@nechclst.in writes:
checking for
i686-pc-linux-gnu-gcc...
/home/abhijitd/gcc/gcc-4.3.2/host-i686-pc-linux-gnu/gcc/xgcc
-B/home/abhijitd/gcc/gcc-4.3.2/host-i686-pc-linux-gnu/gcc/
-B/home/abhijitd/gcc/gcc-4.3.2/i686-pc-linux-gnu/bin/
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include stdio.h
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.world[0]='H';
r.world[1]='\0';
return r;
}
int
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include stdio.h
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
r.world[0]='H';
r.world[1]='\0';
On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include stdio.h
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
2008/12/16 Dennis Clarke dcla...@blastwave.org:
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include stdio.h
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
(Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary does not segfault but prints garbage (probably
Ok thanks for the clear explanation!
Not being able to threat char[] as a string is rather shocking to me though.
Regards,
Michel
Michel Van den Bergh wrote:
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu
8.10 (Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary does not segfault but
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely become valid C1x.
Sent from my iPhone
On Dec 16, 2008, at 8:45 AM, Jan Engelhardt jeng...@medozas.de wrote:
On Tuesday 2008-12-16 17:05,
On Tuesday 2008-12-16 18:01, Sebastian Redl wrote:
Michel Van den Bergh wrote:
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu 8.10
(Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2 has
type
The C standard says no such thing; only integer promotions are
performed. (See 6.5.2.2 of the C99 final draft.)
Ok one more question. Why does this not give a warning then (and runs fine)?
#include stdio.h
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
Sebastian Redl wrote:
Michel Van den Bergh wrote:
That's strange. When I try to compile this with gcc 4.3.2 on Ubuntu
8.10 (Intel core2 duo)
I get
stest.c: In function ‘main’:
stest.c:13: warning: format ‘%s’ expects type ‘char *’, but argument 2
has type ‘char[20]’
The resulting binary
Andrew Thomas Pinski wrote:
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely become valid C1x.
Ah, it's an rvalue array. Good point.
Sent from my iPhone
Advertising on gcc list. Dear me...
On Tuesday 2008-12-16 17:05, Michel Van den Bergh wrote:
Hi,
The following program segfaults when compiled with gcc
but runs fine when compiled with g++ or icc (the intel C compiler)
#include stdio.h
struct Hello {
char world[20];
};
struct Hello s(){
struct Hello r;
On Tue, Dec 16, 2008 at 12:28:10PM +0700, Ha Luong wrote:
I used gcc-4.3.2 to compile the c source(*) and it generated
vmhraddshs instruction when I compiled with -mcpu=8540.
000103A4: 11EB0321 vmhraddshs vr15,vr11,vr0,vr12
You are running into the problem that the Altivec and SPE opcode
Andrew Haley wrote:
Andrew Thomas Pinski wrote:
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely become valid C1x.
Ah, it's an rvalue array. Good point.
Ok now I understand. I assume
On Tue, Dec 16, 2008 at 9:43 AM, Michel Van den Bergh
michel.vandenbe...@uhasselt.be wrote:
Andrew Haley wrote:
Andrew Thomas Pinski wrote:
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely
On Tuesday 2008-12-16 18:43, Michel Van den Bergh wrote:
Andrew Haley wrote:
Andrew Thomas Pinski wrote:
C++98 is not C99 :) there is no rvalue to lvalue conversion for rvalue
arrays in C++98. Also this code is still undefined C99 but will most
likely become valid C1x.
Ah, it's an
On Tue, Dec 16, 2008 at 10:41 AM, Jan Engelhardt jeng...@medozas.de wrote:
Is not this a use of an rvalue array too?:
printf(%p\n, (struct { char x[20]; }){{Hello}}.x);
No, compound literals are always lvalues in C99.
Thanks,
Andrew Pinski
Hi,
./gcc/config/avr/avr.md
defines andsi3 as follows:
(define_insn andsi3
[(set (match_operand:SI 0 register_operand =r,d)
(and:SI (match_operand:SI 1 register_operand %0,0)
(match_operand:SI 2 nonmemory_operand r,i)))]
*{
if (which_alternative==0)
...
On Mon, Dec 15, 2008 at 04:17:34PM -0500, gobaan_raveend...@amis.com wrote:
Hello Everyone,
I am working on an architecture with multiple types of memory and I am
wondering about memory allocation. For the purpose of this explaination,
we'll assume I am working with an embedded processor
I've been studying the x86 compiled form of the following function:
void function()
{
char buffer[X];
}
where X = 0, 1, 2 .. 100
Naively, I would expect to see:
pushl %ebp
movl%esp, %ebp
subl$X, %esp
leave
ret
Instead, the stack appears to
Andrew Tomazos wrote:
I've been studying the x86 compiled form of the following function:
void function()
{
char buffer[X];
}
where X = 0, 1, 2 .. 100
Naively, I would expect to see:
pushl %ebp
movl%esp, %ebp
subl$X, %esp
leave
ret
Hello Everyone,
I am working on an optimization which happens at split2 stage. I need to
determine whether the destination operand of the current RTL (which is a
register operand) will be referred by other RTL through MEM within a basic
block. I see there is a function named reg_mentioned_p
Hi Nathan,
Thanks for your guide. When I debugged the exe file or make it ran on
8548 board, the vmhaddshs makes the exe file hang out. Could I compile
the source for 8540 (e500v1 instructions) only?
Thanks for your help,
Ha Luong
On Tue, Dec 16, 2008 at 9:45 PM, Nathan Froyd
Greetings,
In my efforts to build C++-0X library components I've noticed that
constexpr member variables are used in several places. I was unable to
implement these as intended and reverted to const accessors.
It seems like the intent is sort of a static const function except that
it binds
Guo, Xuepeng xuepeng@intel.com writes:
I am working on an optimization which happens at split2 stage. I
need to determine whether the destination operand of the current RTL
(which is a register operand) will be referred by other RTL through
MEM within a basic block. I see there is a
Hi Ian,
Thanks for your comments. It's not exactly the entire basic block. It should be
from the current RTL to the end of the current basic block. As you know GCC
will optimize addl %ebx, %eax to leal (%ebx, %eax), %eax to avoid the flag
register dependency through a splitter in i386.md at
2008/12/16 Georg-Johann Lay georgjoh...@web.de:
Hi,
./gcc/config/avr/avr.md
defines andsi3 as follows:
[...]
For alternative 1 d,0,i the effect on cc_status is described as set_n.
However, if the high byte of [2] is 0xff, then the PSW (i.e. SREG.N)
does not contain the MSB of the result.
--- Comment #5 from doko at ubuntu dot com 2008-12-16 08:49 ---
The most recent complete build logs can be seen at
http://buildd.debian.org/fetch.cgi?pkg=gcc-snapshotver=20081130-1arch=armelstamp=1228429623file=log
--- Comment #18 from jv244 at cam dot ac dot uk 2008-12-16 11:58 ---
(In reply to comment #17)
BTW, the -O3 compilation is still running (for 17h now).
finished successfully after 23h...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 4.3.0.
Used invokation line for the GNU C++ compiler:
gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3
--- Comment #11 from jakub at gcc dot gnu dot org 2008-12-16 13:09 ---
The problem is that CSE2 extends the live range of CC register, so before DSE1
we have in _ZN11rot_mx_infoC1ERK6rot_mx function:
(insn 15 14 16 2 pr37922.C:469 (set (reg:CC 17 flags)
(compare:CC (reg/v:SI 75
--- Comment #2 from mikael at gcc dot gnu dot org 2008-12-16 15:35 ---
Yes, confirmed.
The offending line is:
call foo(func(_//bar()))
In trans-expr.c, se-loop is NULL in the gcc_assert:
2844 else if (sym-result-attr.dimension)
2845 {
2846 gcc_assert (se-loop
--- Comment #6 from rearnsha at gcc dot gnu dot org 2008-12-16 12:12
---
Fixed on trunk
--
rearnsha at gcc dot gnu dot org changed:
What|Removed |Added
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|4.4.0 |4.3.3
Version|4.4.0 |4.3.2
--- Comment #3 from dominiq at lps dot ens dot fr 2008-12-16 16:03 ---
If the subroutine
subroutine xmain()
call foo(func(_//bar()))
end subroutine xmain
is replaced with
subroutine xmain()
character (len=2) :: zz(2)
zz=func(_//bar())
call foo(zz)
end subroutine xmain
the code
--- Comment #25 from jv244 at cam dot ac dot uk 2008-12-16 16:17 ---
doing some more profiling, the -O0 problem is to a large extend due to
compute_inline_parameters and estimate_stack_frame_size. Spending 10-30min just
on estimating the stack_frame_size on something that can't be
--- Comment #26 from steven at gcc dot gnu dot org 2008-12-16 16:26 ---
I am going to work on the -O0 problems a bit.
The operand scanner is the problem at -O3. Richi, this is one you may want to
try on the alias improvements branch, if most of the time is spent on virtual
SSA names (I
--- Comment #27 from jv244 at cam dot ac dot uk 2008-12-16 16:29 ---
the slow routines at -O3 are related to compute_may_aliases, at the point I
interupted the profiling, this routine had called add_virtual_operand 200M
times.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #1 from hariharans at gcc dot gnu dot org 2008-12-16 16:35
---
This has been fixed on 4.4.0 (trunk)
--
hariharans at gcc dot gnu dot org changed:
What|Removed |Added
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 4.3.0.
Used invokation line for the GNU C++ compiler:
gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3
--- Comment #1 from rearnsha at gcc dot gnu dot org 2008-12-16 16:45
---
I'm unable to reproduce this with any of svn-trunk, gcc-4.1.3 (debian),
gcc-4.3.3 (SVN) or gcc-4.3.2 (debian). The loop essentially reads as
mov r7, #1
mov r6, #0
L5:
...
add r6, r6, #1
cmp r7, r6
--- Comment #5 from rearnsha at gcc dot gnu dot org 2008-12-16 12:04
---
Subject: Bug 37436
Author: rearnsha
Date: Tue Dec 16 12:03:41 2008
New Revision: 142778
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142778
Log:
PR target/37436
* arm.c (arm_legitimate_index): Only accept
--- Comment #19 from steven at gcc dot gnu dot org 2008-12-16 12:45 ---
Re. comment #18, I'd say brilliant if it wasn't such a poor performance :-)
Did you manage to get a time report out of that run?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #3 from jakub at gcc dot gnu dot org 2008-12-16 16:57 ---
In particular, the problem is in linearize_expr_tree. The |s are already
perfectly linearized (in all but the innermost recursive linearize_expr_tree
binlhsisreassoc is 1 and binrhsisreassoc is 0, in the innermost
--- Comment #1 from jakub at gcc dot gnu dot org 2008-12-16 13:49 ---
The culprit is tree-ssa-reassoc.c, with -fno-tree-ssa-reassoc the generated
code is comparable to 3.4.
For some reason it decides:
Transforming err_10 = __err_3 | __err_8;
into err_10 = __err_8 | __err_3;
(no idea
--- Comment #4 from dberlin at gcc dot gnu dot org 2008-12-16 17:00 ---
Subject: Re: [4.2/4.3/4.4 regression] tree-ssa-reassoc.c increases register
pressure several times
Yes, that looks like a bug.
There are also numerous ways in which the placement can be improved.
A few people had
--- Comment #2 from rearnsha at gcc dot gnu dot org 2008-12-16 17:12
---
Confirmed. This appears to be a bug in the register-renaming pass, where the
insn
(insn:HI 84 79 82 8 proc/sysinfo.c:890 (parallel [
(set (reg:CC_NOOV 24 cc)
(compare:CC_NOOV
--- Comment #14 from hjl dot tools at gmail dot com 2008-12-16 17:18
---
Here is the original patch which caused this regression:
http://gcc.gnu.org/ml/gcc-patches/2007-09/msg01582.html
Here is the one checked in:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00744.html
--
hjl
--- Comment #9 from jakub at gcc dot gnu dot org 2008-12-16 12:08 ---
Indeed, -O2 -fpic returns 2, -O2 -fpic -fno-dse returns 0. The difference
between the two are just 4 successful replace_read changes, like:
movq%rdx, 224(%rsp) # D.4704, proper_r
- shrq$32, %rdx
--- Comment #13 from jakub at gcc dot gnu dot org 2008-12-16 15:05 ---
Not doing this optimization if added_clobbers_hard_reg_p would basically kill
it on i386/x86_64 except for constant values, all the shifts clobber hard
registers. But typically flags register is only live for very
--- Comment #20 from jv244 at cam dot ac dot uk 2008-12-16 12:47 ---
(In reply to comment #19)
Re. comment #18, I'd say brilliant if it wasn't such a poor performance :-)
I agree... quite an achievement not to crash in such a case.
Did you manage to get a time report out of that
Dear all,
I would like to post a fault report for the GNU C/C++ compiler 4.3.0.
Used invokation line for the GNU C++ compiler:
gcc -c -x c++ -ansi -Wall -Werror -mcpu=603e -fverbose-asm -mbig
-mmultiple -mstring -mstrict-align -meabi -msdata -fno-common
-fno-exceptions -fno-rtti -O3
--- Comment #2 from hjl dot tools at gmail dot com 2008-12-16 14:58 ---
Sounds similar to PR 32183.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2008-12-16 13:45 ---
Looks like something along the lines of gcse.c:can_assign_to_reg_p() is called
for here in replace_read.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
--- Comment #4 from rearnsha at gcc dot gnu dot org 2008-12-16 17:39
---
Not a bug. You need to write your macro like this:
#define burst_copy(dst,src,len) {\
unsigned t1, t2, t3; \
__asm__ __volatile__ ( \
1: \n\t \
ldmia %1!,{r3-r6} \n\t \
stmia %0!,{r3-r6} \n\t \
--- Comment #10 from jakub at gcc dot gnu dot org 2008-12-16 12:48 ---
Created an attachment (id=16912)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16912action=view)
pr37922.C
Testcase with a bunch of unneeded namespaces removed.
--
--- Comment #24 from jv244 at cam dot ac dot uk 2008-12-16 14:20 ---
(In reply to comment #23)
reduced testcase timings at -O0 and -O3. Tree operand scan anybody?
time gfortran -O0 -ffree-line-length-512 -c -ftime-report testcase_reduced.f90
Execution times (seconds)
garbage
--- Comment #9 from leonid at volnitsky dot com 2008-12-16 13:21 ---
(In reply to comment #8)
int16_t* ip = (int16_t*)m1;
That is violating C/C++ aliasing rules
The code that you quote is not part of the reported bug. It was quick and
dirty hack. But that was it. Adding
--- Comment #4 from mayor1 at uralweb dot ru 2008-12-16 11:34 ---
Subject: Re: namespace, iostream, cstring
On 15 Dec 2008 17:40:49 -
jakub at gcc dot gnu dot org
gcc-bugzi...@gcc.gnu.org wrote:
--- Comment #1 from jakub at gcc dot gnu dot org
2008-12-15 17:40
--- Comment #21 from jv244 at cam dot ac dot uk 2008-12-16 12:48 ---
(In reply to comment #16)
Oh, and FWIW, for yukawa_gn_full, stack_vars_num == 67551 for me.
btw, that routine only has 3800 user variables, the rests are FE generated
temporaries (which should have a limited
--- Comment #15 from hjl dot tools at gmail dot com 2008-12-16 18:41
---
Is that safe to call find_shift_sequence when CC register is live?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37922
--- Comment #13 from tim at bishnet dot net 2008-12-16 14:29 ---
Could this change be merged down to the 4.3 branch? Currently 4.3.2 release is
still broken.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32581
--- Comment #16 from zadeck at naturalbridge dot com 2008-12-16 18:43
---
and how would you ask that question in a machine independent way?
I am going to find the shift sequence and if it has a set or clobber of any
currently live hard reg, i will reject the sequence.
I am working on
--- Comment #22 from steven at gcc dot gnu dot org 2008-12-16 13:41 ---
We may be better off with a slightly reduced test case for the -O3 report.
It's not difficult to cut out ~8000 lines (like I did yesterday) and still have
a huge test case (and the horendous compile times to go
--- Comment #23 from jv244 at cam dot ac dot uk 2008-12-16 14:17 ---
Created an attachment (id=16913)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16913action=view)
reduced testcase
just so we talk about the same file, I've reduced the testcase to more
managable sizes. This one
--- Comment #2 from thutt at vmware dot com 2008-12-16 14:03 ---
(In reply to comment #1)
The reason why they are saved is so that you can have a good way of debugging
noreturn functions.
Can you please elaborate? How is saving these registers, which will never be
restored, going
--- Comment #4 from pinskia at gcc dot gnu dot org 2008-12-16 19:18 ---
Simple testcase:
extern int i;
int i; // ERROR: this is not ok
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-16 19:18 ---
Not a regression.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-12-16 19:21 ---
This has been fixed since 4.3.0:
t.cc:7: error: declaration of 'typedef struct Xint A::X'
t.cc:2: error: changes meaning of 'X' from 'struct Xint'
--
pinskia at gcc dot gnu dot org changed:
What
--- Comment #28 from pinskia at gcc dot gnu dot org 2008-12-16 19:32
---
The stack heuristic is new for 4.3.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
Target Milestone|4.3.4 |4.3.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38474
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 20:37 ---
Why do you want this, this is an free source project after all?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38475
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 20:38 ---
I want to say this is a duplicate of bug 38367.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-16 20:40 ---
we have:
unsigned short foobar;
int i = (int)foobar;
if (i 99)
if (foobar = 99)
access array[i];
so i can never be negative and foobar will never be greater than 99.
This is both a missed optimization
GCC 4.3.2 failed to compile code with vairadic template function
specialization.
Here is the code causing the problem:
template typename ... T void foo( T ... args );
template void foo( int, double ){}
int main()
{
foo( 0, 0.0 );
return 55;
}
I got the following error msg:
test.cpp:3:
--- Comment #2 from m dot j dot thayer at googlemail dot com 2008-12-16
21:48 ---
I just generally don't like having my e-mail address visible on public web
pages. Among other things, it provides food for spam-bots.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38475
The optimizer at -O3 for x86_64 finds opportunities to generate the adc (add
with carry) instruction to avoid a conditional branch. However, the dst of the
adc can only be in a register. The optimizer misses a chance to use adc with
the destination in memory, and will instead use a conditional
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
--- Comment #3 from steven at gcc dot gnu dot org 2008-12-16 23:03 ---
This is not fixable. When a bug is filed, messages are sent out and picked up
by archive mirrors. This is desirable for GCC the project but probably less so
for individual GCC users.
--
steven at gcc dot gnu dot
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
Dear all,
I've notice that the following code does not compile with g++ 4.4.0 (trunk).
It seems to be a regression from g++ 4.3.2, which compiles this code
successfully.
$ cat error.c
class A;
class B
{
void foo(int A,
const A*);
};
$ g++ -Wextra -Wall -c error.cc
error.cc:6:
I configured with:
CONFIG_SHELL=/usr/bin/bash CFLAGS=-O9 -maltivec -mabi=altivec CXXFLAGS=-g
-O9 -maltivec -mabi=altivec CFLAGS_FOR_TARGET=-O9 -maltivec -mabi=altivec
LIBCFLAGS=-g -O9 -maltivec -mabi=altivec LIBCXXFLAGS=-g -O9 -maltivec
-mabi=altivec LIBGCC2_CFLAGS=-g -O9 -maltivec -mabi=altivec
--- Comment #29 from jv244 at cam dot ac dot uk 2008-12-17 06:50 ---
doing the original testcase again at -O3 has been a useful exercise i think.
13.5h is spent in rename_registers, 2h in tree operand scan, ~1h in inline
heuristics, and 20min in expand. (Note that this is a 4.3 based
--- Comment #30 from steven at gcc dot gnu dot org 2008-12-17 07:01 ---
I think redoing this with 4.4.0 would be useful, to check if new code (like
IRA) uses this kind of non-linear algorithms. But the register renaming patch
hasn't changed between 4.3 and 4.4, so I would compile with
Hello,
I get the following duplicate symbols with g++ on AIX.
g++ (GCC) 4.2.4
g++ hello.cpp -o hello (hello.cpp is just a cout hello world...)
ld: 0711-224 WARNING: Duplicate symbol: .__divdi3
ld: 0711-224 WARNING: Duplicate symbol: .__moddi3
ld: 0711-224 WARNING: Duplicate symbol: .__udivdi3
--- Comment #1 from tammer at tammer dot net 2008-12-17 07:29 ---
Created an attachment (id=16914)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16914action=view)
build log of sample
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38547
--- Comment #4 from tkoenig at gcc dot gnu dot org 2008-12-17 07:33 ---
Not a regression:
gfortran ice.f90
ice.f90: In function 'xmain':
ice.f90:8: internal compiler error: in gfc_conv_function_call, at
fortran/trans-expr.c:2846
Please submit a full bug report,
with preprocessed
90 matches
Mail list logo
