-disable-libgcc and/or -disable-fixincludes are useful, depending on your goal.
Like if you just want to compile C to assembly or object files.
It fails, but only after doing what I want anyway.
make[2]: *** No rule to make target
`../build-sparc-sun-solaris2.10/fixincludes/fixinc.sh',
It might also be necessary to configure for i586-sun-solaris2.10 instead of
i586-solaris2.10.
Something I read said you can use various shorter forms, and I like the idea
for convenience and to avoid those pcs and unknowns,
but this seems to have bitten me a number of times, not just today.
On Sun, May 9, 2010 at 3:22 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sun, May 9, 2010 at 5:09 AM, ajmcello ajmcell...@gmail.com wrote:
I've got a quad core 3.2Ghz FreeBSD-8 system with 8GB of ram. I
compiled and installed Cloog-PPL and PPL, mpfr, gmp, mpc, polylib,
etc. I'm
On Mon, 10 May 2010, Jay K wrote:
It seems using GNU as might still be slightly preferred in order to move
data (jump tables) out of .text and into read only data, like, you know,
the less that is executable, the more secure. Though for locality,
.text might be better.
Note that you can
Hi,
I have a problem to compile the libgcc2 with a new gcc backend.
I have a little processor with 4 registers A X Y and R0(0) with 32 Bit.
R0(0) is the stackpointer and Y is the basepointer.
So i only have the registers A and X to calculate.
It always gave me an error that there are to less
On x86_64-apple-darwin10, we fail the lto testcase...
/sw/src/fink.build/gcc46-4.5.999-20100508/darwin_objdir/gcc/xgcc
-B/sw/src/fink.build/gcc46-4.5.999-20100508/darwin_objdir/gcc/ -O0 -fwhopr -c
-o c_lto_20081222_1.o
Hello,
We have just merged the branch st/cli-fe (a gcc front end for CLI)
from a 4.3 realse to 4.5.
This merge has broken the compiler and for a simple helloworld test it
fails with the error
cil1: internal compiler error: in execute_one_pass, at passes.c:1525
This error is reporting that the
On 10/05/2010 14:30, Jack Howarth wrote:
Are there any standards in effect which would dictate that
the alias of a hidden function is valid?
Visiblity doesn't apply to functions, it applies to symbols. Symbols are
textual names with a linked value that exist in object files. The compiler
On Mon, May 10, 2010 at 04:17:26PM +0100, Dave Korn wrote:
On 10/05/2010 14:30, Jack Howarth wrote:
Are there any standards in effect which would dictate that
the alias of a hidden function is valid?
Visiblity doesn't apply to functions, it applies to symbols. Symbols are
textual
On 10/05/2010 16:19, Jack Howarth wrote:
Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4
20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'
which I assume means this error message is coming from the compiler and not
the linker. So it still unclear to me if
On 10/05/2010 17:16, Dave Korn wrote:
On 10/05/2010 16:19, Jack Howarth wrote:
Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4
20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'
The error comes from finish_aliases_1 in varasm.c, where it is suppressed in
Jay K jay.kr...@cornell.edu writes:
-disable-libgcc and/or -disable-fixincludes are useful, depending on your
goal.
Like if you just want to compile C to assembly or object files.
It fails, but only after doing what I want anyway.
make[2]: *** No rule to make target
On 05/10/2010 12:39 AM, Ian Lance Taylor wrote:
Albert Cohenalbert.co...@inria.fr writes:
I agree. Or even, =c++0x or =gnu++0x
On the other hand, I fail to see the differen between =single and
=fast, and the explanation about the same memory word is not really
relevant as memory models
On Fri, May 7, 2010 at 7:09 AM, Karel Gardas gard...@gmail.com wrote:
with recent fixes into profile mode I've succeed even using it for
MICO[1] on OpenSolaris platform. Is there any tool which
translates call stacks to humans or is there any documentation/hint
how to use generated call stack
I am trying to speedup the load and startup time of a shared library.
After reading Ulrich Drepper's paper on How to write shared libraries,
it seems that the easiest thing to try would be to reduce the number of
symbols that are globally visible. After carefully adding
On Mon, May 10, 2010 at 05:20:22PM +0100, Dave Korn wrote:
On 10/05/2010 17:16, Dave Korn wrote:
On 10/05/2010 16:19, Jack Howarth wrote:
Compiler executable checksum: c54eb6db87684e4d5a5bb9ad02c2b2c4
20081222_1.c:16: error: 'EXT_x' aliased to undefined symbol 'INT_x'
The error
Ok if I do both or the emails are just annoying?
I find that bugs are often ignored just as well (but not lost/forgotten,
granted. :) )
Thanks,
- Jay
To: jay.kr...@cornell.edu
CC: gcc@gcc.gnu.org
Subject: Re: -disable-fixincludes doesn't quite
Vivek Verma vve...@ilm.com writes:
I am trying to speedup the load and startup time of a shared
library. After reading Ulrich Drepper's paper on How to write shared
libraries, it seems that the easiest thing to try would be to reduce
the number of symbols that are globally visible. After
Jay K jay.kr...@cornell.edu writes:
Ok if I do both or the emails are just annoying?
As far as I'm concerned, it's fine to do both.
I find that bugs are often ignored just as well (but not lost/forgotten,
granted. :) )
Agreed on both counts.
Ian
On Sat, May 8, 2010 at 2:52 PM, Amker.Cheng amker.ch...@gmail.com wrote:
Ah, I forgot pro/epilogue generation, but I think that's the only other
thing that happens after reload. That is a special case: it has to generate
strict rtl that directly matches the insns it wants. You'll probably
Richard Earnshaw wrote:
Speaking of which, we should probably formally deprecate the old arm-elf
derived targets in 4.6 so that we can remove them in 4.7.
Similarly, we should deprecate support for the FPA on ARM.
I agree.
--
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385
Hi :
I'm working on a fpu which cannot work fpload insns right, so I have
to use a GPR
reg as temp reg to first load mem into GPR then move GPR into fpu register.
I have handled most cases but the case gcc handling call clobbered fpu
registers.
since it is in reload pass, I have no available
A common technique is to benchmark a function by calling it many times i.e.
void foo(void);
int main(void)
{
}
--
Summary: benchmark function attribute.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
--- Comment #1 from svfuerst at gmail dot com 2010-05-10 06:36 ---
A common technique is to benchmark a function by calling it many times i.e.
void foo(void)
{
/* foo's implementation */
}
int main(void)
{
int i;
for (i = 0; i LARGE_NUM; i++) foo();
return 0;
}
The
--- Comment #2 from steven at gcc dot gnu dot org 2010-05-10 06:55 ---
Re. comment #1:
(1) For this, there is the noinline attribute, as you already knew.
(2) See the noclone attribute
(3) See the regparm attribute
(4) You could use volatile and things like that, or put the unit in a
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-10 07:55 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--
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
--- Comment #11 from jakub at gcc dot gnu dot org 2010-05-10 07:59 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #16 from irar at il dot ibm dot com 2010-05-10 08:17 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #6 from rguenther at suse dot de 2010-05-10 08:41 ---
Subject: Re: Optimizing integer power
On Sun, 9 May 2010, dfranke at gcc dot gnu dot org wrote:
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-09 21:08
---
Situation still the same with gcc
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-10 08:55 ---
Subject: Bug 44050
Author: rguenth
Date: Mon May 10 08:55:32 2010
New Revision: 159214
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159214
Log:
2010-05-10 Richard Guenther rguent...@suse.de
PR
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-05-10 08:56 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-10 09:13 ---
4) is already fine with noclone,noinline
for 3) you can add artificial side-effects by an empty asm();
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44053
--- Comment #4 from burnus at gcc dot gnu dot org 2010-05-10 10:05 ---
(In reply to comment #2)
... should give a runtime error, since fun(0) evaluates to NULL.
F08 section 16.5.1.6 demands that, if the selector is a pointer, it should be
associated.
In the same way, having an
--- Comment #2 from burnus at gcc dot gnu dot org 2010-05-10 10:10 ---
I/O: Currently both READ an WRITE map to the same function; this should be
changed such that for WRITE the arguments are marked as EAF_NOCLOBBER. This can
be done using aliases, cf.
--- Comment #9 from jakub at gcc dot gnu dot org 2010-05-10 10:13 ---
Created an attachment (id=20617)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20617action=view)
gcc46-pr44023.patch
The bug is that if a debug insn references more than one dead pseudo, only the
first one is
The middle end now supports besides -Werror also -Werror=list, where
-Werror=foo implies -Wfoo. Additionally, the middle end also annotates via
-fdiagnostics-show-option (enabled by default) the messages with the
warning-flag name in parentheses:
-Wuninitialized (or, e.g.: -Wall)
foo.c:4:2:
--- Comment #1 from burnus at gcc dot gnu dot org 2010-05-10 10:30 ---
-Werror= was added 2006 (
http://gcc.gnu.org/viewcvs?view=revisionrevision=109907 ) and the
-fdiagnostics-show-option already exists since 2005
(http://gcc.gnu.org/viewcvs?view=revisionrevision=99169 ) - though it
With the patch http://gcc.gnu.org/ml/fortran/2010-05/msg00067.html (for PR
27866, PR 35003, PR 42809) the number of conversion warnings has drastically
been cut down by drastically cutting down the number of unintended warnings.
However, it no longer warns for
real(8) :: sqrt2
sqrt2 =
--- Comment #20 from mkuvyrkov at gcc dot gnu dot org 2010-05-10 10:46
---
Subject: Re: this fortran program is too slow
On 5/7/10 1:38 AM, steven at gcc dot gnu dot org wrote:
--- Comment #19 from steven at gcc dot gnu dot org 2010-05-06 21:38
---
One possibility is to
--- Comment #4 from steven at gcc dot gnu dot org 2010-05-10 11:00 ---
In other words: not an issue.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Tried native compile gcc-4.50 on both x86_64-linux and i686-linux, and install
into separate directory, it can compile small plugin demo, and demo plugin also
worked well;
but while writing a useful gcc plugin with FOR_EACH_LOOP from cfgloop.h, it
exited with error:
gcc -I.
bin/bash: ar: command not found
gmake[2]: *** [libiberty.a] Error 127
gmake[2]: Leaving directory `/home/jkrell/obj/gcc.x86.sol9/libiberty'
gmake[1]: *** [all-libiberty] Error 2
gmake[1]: Leaving directory `/home/jkrell/obj/gcc.x86.sol9'
gmake: *** [all] Error 2
This is a common occurence for
--- Comment #5 from burnus at gcc dot gnu dot org 2010-05-10 11:51 ---
James Van Buskirk post:
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7681f2c8f86c4687/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19168
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-10 12:51 ---
+1 for the idea of a new plugin category.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44056
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-10 12:54 ---
Subject: Bug 44044
Author: janus
Date: Mon May 10 12:54:25 2010
New Revision: 159217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159217
Log:
2010-05-10 Janus Weil ja...@gcc.gnu.org
PR
--- Comment #1 from michael dot a dot richmond at nasa dot gov 2010-05-10
12:58 ---
In http://gfortran.org/download/ there is a binary built from this snapshot.
Was the source code patched?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44048
--- Comment #1 from baldrick at gcc dot gnu dot org 2010-05-10 13:17
---
This bug fires when trying to build LLVM using trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44017
Build_Class_Wide_Master in exp_ch3.adb starts with this check:
-- Nothing to do if there is no task hierarchy
if Restriction_Active (No_Task_Hierarchy) then
return;
end if;
This early return should obviously also occur if tasking is not allowed, for
example if the
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-10 13:26 ---
Created an attachment (id=20618)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20618action=view)
gcc46-pr44028.patch
Untested fix.
--
jakub at gcc dot gnu dot org changed:
What|Removed
With g++ 4.5.0 static initializers can be executed more than once.
Here's how. Let a.cc contain the following code:
#include stdio.h
struct A {
A() {
static int x = printf(x initialized at @%p\n, x);
}
};
extern C void inita();
void inita()
{
A x;
A y;
}
And let b.cc be the copy
--- Comment #1 from ivan dot stankovic at avl dot com 2010-05-10 13:40
---
Created an attachment (id=20619)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20619action=view)
The test case
Just unpack and run 'make; make run'. The output
should be something like:
x initialized at
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-10 13:54 ---
It works for me. You need to build shared libraries with -fPIC.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-05-10 13:57 ---
Or rather as you use dlopen you need to use RTLD_GLOBAL.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44059
--- Comment #10 from ubizjak at gmail dot com 2010-05-10 13:58 ---
(In reply to comment #9)
I'll bootstrap/regtest the patch on x86_64-linux and i686-linux, Uros, can you
please do the same on alpha*-*?
The patch bootstraps OK on alphaev68-pc-linux-gnu. Regression test just
started,
--- Comment #13 from hjl at gcc dot gnu dot org 2010-05-10 14:02 ---
Subject: Bug 44012
Author: hjl
Date: Mon May 10 14:02:43 2010
New Revision: 159223
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159223
Log:
Nullify regno_allocno_map of the removed allocno.
gcc/
2010-05-10
--- Comment #19 from dougmencken at gmail dot com 2010-05-10 14:03 ---
It works on powerpc-uclibc host, but if bootstrapped the following way:
Configured with: ./configure --prefix=/usr --sysconfdir=/etc
--mandir=/usr/share/man --build=powerpc-gnu-linux-uclibc
--- Comment #14 from hjl at gcc dot gnu dot org 2010-05-10 14:05 ---
Subject: Bug 44012
Author: hjl
Date: Mon May 10 14:05:16 2010
New Revision: 159224
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159224
Log:
Nullify regno_allocno_map of the removed allocno.
gcc/
2010-05-10
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-10 14:09 ---
Re: #c2, that's just because you are using too old binutils I guess.
The bug seems to be in:
.type _ZGVZN1AC1EvE1x, @object
.type _ZZN1AC1EvE1x, @gnu_unique_object
I believe the guard needs to be
--- Comment #5 from ivan dot stankovic at avl dot com 2010-05-10 14:14
---
Indeed, using RTLD_GLOBAL works around the problem. However, I don't think
one should just resort to using this flag with dlopen everywhere. The problem
was originally found with Python modules written in C, and
Gcc 4.5 miscompiles the following code:
char buf[1024];
void add_input_file(int file)
{
(*((int **)buf))[0] = file;
}
it results in this asm:
Disassembly of section .text:
add_input_file:
0: c3 ret
The file argument is completly ignored.
gcc4.4
int a[2];
int foo (int q)
{
if (__builtin_constant_p (q))
{
if (q == 4)
return a[4];
else
return a[0];
}
else
return a[q];
}
--
Summary: [4.5/4.6 Regression] Warns about out-of-bounds array
access inside
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-10 14:38 ---
I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-10 14:39 ---
I guess the problem is in the !DECL_ARTIFICIAL (DECL) test in
ASM_DECLARE_OBJECT_NAME macro - the guard is artificial.
Not sure why that has been added.
/* For template static data member instantiations or
--- Comment #7 from jakub at gcc dot gnu dot org 2010-05-10 14:39 ---
Reopening.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #1 from schwab at linux-m68k dot org 2010-05-10 14:43 ---
Try -Wstrict-aliasing.
--
schwab at linux-m68k dot org changed:
What|Removed |Added
--- Comment #5 from svfuerst at gmail dot com 2010-05-10 14:53 ---
The problem is that the list of these workarounds tends to increase with each
release of gcc. (i.e. noclone was added in gcc 4.5) It would be nice if there
was a single attribute to use that would work with all future
--- Comment #2 from bernhardloos at googlemail dot com 2010-05-10 14:57
---
(In reply to comment #1)
Try -Wstrict-aliasing.
It does produce a warning about dreferencing a type-punned pointer.
I tried to compile the snipped with both -fstrict-aliasing and
-fno-strict-aliasing and it
Doing
(void)var;
does not 'use' the var, eg:
void f()
{
int i = 6; // or a fn call whose return value you don't care about
(void)i;
}
j...@shade:~$ g++ -Wall -Wextra unused.cpp
unused.cpp: In function void f():
unused.cpp:3:8: warning: variable i set but not used
--- Comment #3 from vmakarov at redhat dot com 2010-05-10 15:22 ---
It is caused by revision 152533:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00182.html
If it is so, the patch triggered some reload bug IMO. The patch itself was
very safe because it resulted in creation of
--- Comment #9 from jason at gcc dot gnu dot org 2010-05-10 15:30 ---
The testcase is invalid; 5.17 doesn't allow assignment to an array from an
initializer list (although I'm not sure why not). But certainly we should give
an error rather than crash.
--
jason at gcc dot gnu dot
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-10 15:32 ---
It is caused by revision 158806:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg00913.html
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-10 15:48 ---
Oops, seems something I should have covered in the testsuite. For C it works
correctly.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-10 15:51 ---
Created an attachment (id=20620)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20620action=view)
testcases
2 new testcases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44062
--- Comment #4 from ramana at gcc dot gnu dot org 2010-05-10 16:03 ---
Confirmed - marking as a target bug .
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-10 16:16 ---
Gcc 4.6 generates expected code.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #20 from dougmencken at gmail dot com 2010-05-10 16:23 ---
But how to rebuild binutils to remove libgcc_s.so.1 dependency from ld?
$ ./print-sharedlib-deps.sh /usr/bin/ld
/usr/bin/ld:
libz.so.1
libc.so.0
libgcc_s.so.1
Now I'm using libgcc_s.so.1
--- Comment #4 from pluto at agmk dot net 2010-05-10 16:26 ---
(In reply to comment #3)
Gcc 4.6 generates expected code.
PR43987 dupllication?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44060
With revision 159199 the trunk built for cris-elf.
With revision 159204 and on, including at least 159229, build was broken as
follows:
/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/xgcc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/./gcc/ -nostdinc
-B/tmp/hpautotest-gcc1/cris-elf/gccobj/cris-elf/newlib/
--- Comment #21 from pluto at agmk dot net 2010-05-10 16:31 ---
(In reply to comment #20)
But how to rebuild binutils to remove libgcc_s.so.1 dependency from ld?
configure binutils with --disable-shared --enable-static and build
with make AM_LDFLAGS=-all-static. you also need to have
--- Comment #1 from hp at gcc dot gnu dot org 2010-05-10 16:35 ---
Created an attachment (id=20621)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20621action=view)
Preprocessed code, slightly reduced.
Compile with ./cc1 -O2 t.i, observe ICE as in the description.
--
--- Comment #5 from bernhardloos at googlemail dot com 2010-05-10 16:48
---
It is a duplicate, my problem happens in exactly the same place.
Sorry I missed the other bug.
*** This bug has been marked as a duplicate of 43987 ***
--
bernhardloos at googlemail dot com changed:
--- Comment #21 from bernhardloos at googlemail dot com 2010-05-10 16:48
---
*** Bug 44060 has been marked as a duplicate of this bug. ***
--
bernhardloos at googlemail dot com changed:
What|Removed |Added
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-10 16:50 ---
Created an attachment (id=20622)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20622action=view)
gcc46-pr44062.patch
Actually, I've found 2 issues even in the C FE related to comma expressions
with
LHS or RHS
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-10 16:58 ---
This probably superseeds (accompanies?) PR31601.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #16 from ubizjak at gmail dot com 2010-05-10 17:01 ---
On alphaev68-pc-linux-gnu, I'm getting:
make[4]: Entering directory
`/space/uros/gcc-build/alphaev68-unknown-linux-gnu/boehm-gc'
Switched to incremental mode
Emulating dirty bits with mprotect/signals
Completed 3 tests
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-10 17:02 ---
I think -Wconversion-extra would be a good choice.
We could enable -Wconversion with -Wall and -Wconversion-extra with -Wextra?!
--
dfranke at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 27866
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 35003
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
--- Comment #7 from dfranke at gcc dot gnu dot org 2010-05-10 17:11 ---
Subject: Bug 42809
Author: dfranke
Date: Mon May 10 17:10:53 2010
New Revision: 159238
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159238
Log:
gcc/fortran/:
2010-05-10 Daniel Franke
The following testcase segfaults in 4.6:
module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type inner
type :: myclass
type(inner) :: slice
end type myclass
contains
subroutine set(this)
class(inner),
--- Comment #11 from ubizjak at gmail dot com 2010-05-10 17:15 ---
(In reply to comment #10)
I'd say that the patch is OK.
Regression test results at [1], everything looks OK.
[1] http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00960.html
--
--- Comment #8 from mikael at gcc dot gnu dot org 2010-05-10 17:16 ---
(In reply to comment #7)
With -fwhole-file I now get the same timings either way. I call that fixed.
Unless there is one other bug tracking inlining of use-associated functions,
one cannot close this yet.
The
--- Comment #3 from burnus at gcc dot gnu dot org 2010-05-10 17:16 ---
(In reply to comment #2)
This probably superseeds (accompanies?) PR31601.
Not really. This is about warnings - the other is about errors due to -std=.
For warnings, the purpose is to help fine-tuning the warnings -
In the following testcase (tested against 4.6), a procedure bound to an
attribute of a super class is not resolved in the subclass.
The test case below doesn't go through the linker.
The error message is:
gfortran -c -ffree-form module.f test.f
gfortran -o test test.o module.o
module.o: In
--- Comment #10 from dougsemler at gmail dot com 2010-05-10 17:18 ---
Well, is it really invalid code with -std=c++0x?
The virutal destructor seems to be causing the issue.
With gcc 4.4.3 (after changing virtual ~base() to virtual void func()):
$ g++ gcc_bug.cc
gcc_bug.cc: In
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-10 17:19 ---
On x86_64-apple-darwin10 at revision 159234 (+ a few patches) I get:
[macbook] f90/bug% gfc pr44064.f90
Undefined symbols:
_vtab$inner.1583, referenced from:
___module_mysubclass_MOD_init in cc4CUNex.o
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-10 17:21 ---
On powerpc-apple-darwin9 at revision 159191 (without gfortran patch) I get:
[karma] f90/bug% gfc pr44064.f90
/var/tmp//ccpUV3i0.s:65:non-relocatable subtraction expression,
_vtab$inner.1183 minus L001$pb
--- Comment #22 from redi at gcc dot gnu dot org 2010-05-10 17:28 ---
(In reply to comment #17)
So can you please tell me how to install libgcc then?
make install should do it. if it's not, look to see if libgcc_s.so is built,
is it in the build tree? does the one in the build tree
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-10 17:32 ---
On x86_64-apple-darwin10, I do not see any difference between this PR and
pr44064. On powerpc-apple-darwin9, I get the errors reported in pr44064#c2 when
compiling the module file.
--
1 - 100 of 157 matches
Mail list logo
