wide-ranging fails:
=== libgomp Summary for unix/-m32 ===
# of expected passes2466
# of unexpected failures24
# of unsupported tests 2
=== libgomp Summary for unix/-m64 ===
# of expected passes2365
# of unexpected failures
--- Comment #3 from kasparek at fit dot vutbr dot cz 2010-05-14 06:50
---
(In reply to comment #1)
> to get the cc1 command line. Then use gdb --args to debug the
> compiler. Getting a backtrace before the abort would be nice.
(gdb) bt
#0 open_file (file=0x8a64148) at
/usr/local/l
--- Comment #2 from iains at gcc dot gnu dot org 2010-05-14 06:42 ---
the working output (const-str-9.s) is:
.lazy_reference .objc_class_name_NSConstantString
.comm __NSConstantStringClassReference,4,2
.const
.align 2
LC0:
.ascii "MyApp\0"
.objc_c
--
dodji at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org
|dot org
--- Comment #3 from dodji at gcc dot gnu dot org 2010-05-14 06:41 ---
Subject: Re: wrong location description for
DW_AT_vtable_elem_location
> Dodji, want to look at this?
Sure.
Like, Jakub said, we need to synchronize with GDB. I'll test Jakub's
patch ASAP and push the change when G
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-14 06:39 ---
r159321 caused this.
I think this is a case where we are generating initialization of a class -
maybe we're not marking something the way that is expected?
ccing Jan.
--
iains at gcc dot gnu dot org changed:
--- Comment #11 from socketpair at gmail dot com 2010-05-14 06:31 ---
Suppose this:
volatile int x;
asm("something"::"a" (1))
x=1;
the compiler may think that "something" do not modify eax. So next assignment
may use eax ( mov eax, x ). So, "it does not make sense to have it as a
clobb
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-14 06:22 ---
see:
http://gcc.gnu.org/ml/gcc-patches/2010-05/msg01030.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43689
--- Comment #1 from kargl at gcc dot gnu dot org 2010-05-14 05:34 ---
Copying your code into uh.f90 gives
laptop:kargl[204] gfc4x -o z uh.f90
laptop:kargl[205] ./z
Derived DoIt
with i686-*-freebsd and x86_64-*-freebsd on trunk.
--
kargl at gcc dot gnu dot org changed:
This problem is best illustrated by the following piece of code
module BaseModule
type, abstract :: BaseType
contains
procedure (DoAbstract), deferred, pass :: DoIt
end type
abstract interface
subroutine DoAbstract(self)
! import :: BaseType
class(BaseType) :: self
--- Comment #1 from hjl at gcc dot gnu dot org 2010-05-14 05:10 ---
Subject: Bug 44130
Author: hjl
Date: Fri May 14 05:10:02 2010
New Revision: 159384
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159384
Log:
Increase base_name alignment if needed.
gcc/
2010-05-13 H.J. Lu
On vect256 branch, I got
[...@gnu-6 prxxx]$ cat x.c
extern void abort (void);
static float Yf[] = { 2.0, -2.0, -2.0, -2.0, -2.0, 2.0, -0.0, __builtin_inff ()
};
static const float Zf[] = { 1.0, -1.0, -1.0, -0.0, -0.0, 0.0, -__builtin_inff
(), __builtin_nanf ("") };
void testf (void)
{
float r[
--- Comment #3 from pzhao at gcc dot gnu dot org 2010-05-14 03:19 ---
Subject: Bug 30566
Author: pzhao
Date: Fri May 14 03:19:32 2010
New Revision: 159383
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159383
Log:
gcc/cp/
2010-05-14 Shujing Zhao
PR c++/30566
--- Comment #10 from pinskia at gcc dot gnu dot org 2010-05-14 02:44
---
Because the way the constraints are implemented inside GCC, an input constraint
cannot overlap with a clobber. As input constraint can stay in the same
register across the inline-asm so it does not make sense to h
I believe there is an optimization bug in gcc-4.5.0. When building with
gcc-4.5.0 and setting the linux kernel flag CONFIG_CC_OPTIMIZE_FOR_SIZE, the
kernel indicates a segfault upon boot.
Tested with the normal sysvinit and bash-static and the indication is the
identical memory address with the
--- Comment #1 from jeffrey dot donner at gmail dot com 2010-05-14 02:23
---
Occurs in GCC 4.5.1 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44106
--- Comment #1 from amodra at gcc dot gnu dot org 2010-05-14 00:35 ---
Subject: Bug 44075
Author: amodra
Date: Fri May 14 00:35:16 2010
New Revision: 159382
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159382
Log:
PR target/44075
* config/rs6000/rs6000.c (struc
--- Comment #2 from iains at gcc dot gnu dot org 2010-05-13 23:39 ---
fixed by r159377
--
iains at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #1 from steven at gcc dot gnu dot org 2010-05-13 23:33 ---
Confirmed, this is a case where a def could be sunk closer to its first use.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
This bug is a follow-up to bug c++/44122.
Given the following program:
$ cat t.c
typedef long Py_ssize_t;
void bar() {
typedef int Py_ssize_t;
Py_ssize_t pos;
}
When compiled with the C compiler with -Wshadow flag, a shadow warning is
emitted.
$ gcc -c t.c -Wshadow
t.c: In function bar:
--- Comment #11 from iains at gcc dot gnu dot org 2010-05-13 22:52 ---
(In reply to comment #10)
> (In reply to comment #9)
> > Thanks.
>
> between 159348 and 159356
> will try and refine - but those changes look kinda connected
looks like it is 159354.
159353 is OK and the logs for
--- Comment #4 from rth at gcc dot gnu dot org 2010-05-13 22:41 ---
The only thing "wrong" with the code from -O1 is that it didn't inline __ffs.
Since that function isn't explicitly marked inline, I don't see anything wrong
with that decision.
Given that adding "static inline" to the d
--- Comment #10 from iains at gcc dot gnu dot org 2010-05-13 21:59 ---
(In reply to comment #9)
> Thanks.
between 159348 and 159356
will try and refine - but those changes look kinda connected
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 21:48 ---
If I understand it well, we should:
--- dwarf2out.c 2010-05-13 23:36:24.0 +0200
+++ dwarf2out.c2010-05-13 23:55:07.422464196 +0200
@@ -17094,10 +17094,19 @@ add_pure_or_virtual_attribute (dw_die_re
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-05-13 21:43 ---
(In reply to comment #2)
> Yes, poor is a better word.
>
> And by poor, I mean that gcc produces many superfluous loads and stores and
> even a branch.
Yes -O1 is by design produces extra loads/stores in some cases
--- Comment #2 from mattst88 at gmail dot com 2010-05-13 21:40 ---
(In reply to comment #1)
> What do you mean by "bad"? If the code isn't correct, "wrong" is better
> suited; if it is suboptimal, "poor" is better suited.
>
> If the latter, it's expected that -O1 generates poorer code
--- Comment #5 from danglin at gcc dot gnu dot org 2010-05-13 21:09 ---
I should mention that the data segment size is set to 2097152 kbytes on
the hpux machine where I see this error. Due to the segmented architecture of
the 32-bit runtime on hpux, making this bigger isn't going to hel
--- Comment #4 from danglin at gcc dot gnu dot org 2010-05-13 21:00 ---
This was introduced in revision 159097:
2010-05-06 Jan Hubicka
* cgraphbuild.c (record_reference_ctx): Add varpool_node.
(record_reference, mark_address, mark_load, mark_store): Record
re
--- Comment #9 from paolo dot carlini at oracle dot com 2010-05-13 20:57
---
Thanks.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirm
The following code calls terminate() at runtime because copying the exception
object into the catch parameter throws an exception:
struct A
{
A() { }
A (const A&) { throw 1; }
};
int main()
{
try
{
throw A();
}
catch (A) { }
}
In G++ 3.4 this was handled by just leaving the
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|major |normal
Component|c |other
http:/
--- Comment #22 from dfranke at gcc dot gnu dot org 2010-05-13 20:44
---
Janus, is there something left to do here?
If yes, are summary and keywords still appropriate?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from jason at gcc dot gnu dot org 2010-05-13 20:42 ---
"An entry for a virtual function also has a DW_AT_vtable_elem_location
attribute whose value contains a location description yielding the address of
the slot for the function within the virtual function table for the e
Consider this simple example:
class K {
public:
virtual int x() { return 23; }
};
K k;
This yields this attribute in the dwarf:
<7a> DW_AT_vtable_elem_location: 2 byte block: 10 0 (DW_OP_constu: 0)
However, this is incorrect.
The location description ought to compute the address o
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-05-13 20:34
---
I believe this is fixed now.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from iains at gcc dot gnu dot org 2010-05-13 20:31 ---
(In reply to comment #7)
> Yes, we need the help of people running darwin, on x86_64-linux (-m64) too the
> problem cannot be reproduced.
I've just built a reghunt tree ;-)
starting a successive approx. @159348 ...
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-05-13 20:27
---
What do you mean by "bad"? If the code isn't correct, "wrong" is better
suited; if it is suboptimal, "poor" is better suited.
If the latter, it's expected that -O1 generates poorer code than -O2/-O3/-Os.
--
--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-13 20:25
---
Yes, we need the help of people running darwin, on x86_64-linux (-m64) too the
problem cannot be reproduced.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--- Comment #6 from hjl dot tools at gmail dot com 2010-05-13 20:07 ---
What is the first revision failed on darwin?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
compiling at -O0 makes no difference (neither does -mmacosx-version-min=10.4,
which should eliminate the Object1.h header from the enquiry).
===
most of the (usually) emitted code is missing; all that remains is:
.lazy_reference .objc_class_name_NSConstantString
.comm __NSConstantStringCl
Tested revisions:
r159348 - fail
r158969 - fail
I couldn't reproduce it with x86_64 host, even with -m32
Compiler flags:
gcc -O1 -finline-small-functions -fipa-sra -ftree-pre
$ valgrind -q
/mnt/svn/gcc-trunk/binary-159348-x86-lto-fortran/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1
/usr/portage/distf
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-13 19:41 ---
(In reply to comment #4)
> libstdc++ tests are clean on Linux/ia32 as of revision 159368:
> http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg01212.html
fails also on powerpc-apple-darwin9
last pass from regress:
Date
--- Comment #7 from jvdelisle at verizon dot net 2010-05-13 19:37 ---
Subject: Re: gfortran fails to "work" during build
On 05/13/2010 10:17 AM, johnkhord at gmail dot com wrote:
> --- Comment #5 from johnkhord at gmail dot com 2010-05-13 17:17 ---
> (In reply to comment #3)
>
Given the simple test program
# define __kernel_cttz(x) __builtin_ctzl(x)
unsigned long __ffs(unsigned long word)
{
/* Whee. EV67 can calculate it directly. */
return __kernel_cttz(word);
}
long foo(const unsigned long *b)
{
unsigned long b0, b1, ofs, tmp;
b0 = b[0];
b1 = b[1];
ofs
--- Comment #4 from hjl dot tools at gmail dot com 2010-05-13 19:23 ---
libstdc++ tests are clean on Linux/ia32 as of revision 159368:
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg01212.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44121
--- Comment #3 from paolo dot carlini at oracle dot com 2010-05-13 19:12
---
HJ, can you pin point the regressing revision? Thanks.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
--- Comment #2 from paolo dot carlini at oracle dot com 2010-05-13 19:10
---
Seems pretty obvious to me that this is *not* a libstdc++ issue. I'm
tentatively categorizing it as middle-end and adding Honza due to Comment #2.
--
paolo dot carlini at oracle dot com changed:
Here is the complete error message:
g++ -c t.cc
t.cc: In function Âint bar()Â:
t.cc:8:18: error: cannot convert ÂPy_ssize_t*Â to ÂPy_ssize_t*Â for argument
Â1Â to Âint foo(Py_ssize_t*)Â
How is that even possible?
cat t.cc
typedef long Py_ssize_t;
int foo(Py_ssize_t *);
int bar() {
--- Comment #5 from hjl dot tools at gmail dot com 2010-05-13 18:48 ---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 18:47 ---
also:
FAIL: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc (test for excess errors)
Excess errors:
/GCC/gcc-live-trunk/libstdc++-v3/testsuite/27_io/basic_stringbuf/in_avail/wchar_t/1.cc:53:1:
error: Inline clone with addr
m32 and m64:
FAIL: 27_io/basic_stringbuf/in_avail/char/1.cc (test for excess errors)
WARNING: 27_io/basic_stringbuf/in_avail/char/1.cc compilation failed to produce
executable
FAIL: 27_io/basic_stringbuf/in_avail/wchar_t/1.cc (test for excess errors)
WARNING: 27_io/basic_stringbuf/in_avail/wchar_t
--- Comment #15 from jingyu at google dot com 2010-05-13 18:09 ---
Patch was committed to trunk (4.6) r158138.
Resolved.
--
jingyu at google dot com changed:
What|Removed |Added
-
--- Comment #48 from tkoenig at gcc dot gnu dot org 2010-05-13 18:04
---
Any news on this?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-13 17:54
---
Fixed for 4.6.0 by the patch which fixed PR34491.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #6 from kargl at gcc dot gnu dot org 2010-05-13 17:49 ---
(In reply to comment #4)
> Never mind -- according to other bug entries, apparently gcc-4.4.3 (and
> presumeably 4.4.4) requires glibc 2.6
>
glibc 2.6 is not required for gcc-4.4.3 or gcc-4.4.4.
--
http://gcc.gn
--- Comment #9 from paolo dot carlini at oracle dot com 2010-05-13 17:28
---
Nope.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|blocker |normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
--- Comment #5 from johnkhord at gmail dot com 2010-05-13 17:17 ---
(In reply to comment #3)
> (In reply to comment #2)
> > I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now
> > getting a new nastygram when make-ing gcc
>
> No but building in the source directo
--- Comment #4 from johnkhord at gmail dot com 2010-05-13 17:15 ---
Never mind -- according to other bug entries, apparently gcc-4.4.3 (and
presumeably 4.4.4) requires glibc 2.6
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44105
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-05-13 17:14 ---
(In reply to comment #2)
> I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now
> getting a new nastygram when make-ing gcc
No but building in the source directory is not recommended.
--
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-05-13 17:13 ---
Confirmed. Though with the 4.5.0 and above we do have a debug_stmt with the
correct line info at the tree level ...
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #2 from johnkhord at gmail dot com 2010-05-13 17:12 ---
I re-compiled both GMP and MPFR (using the --with-gmp directive) and am now
getting a new nastygram when make-ing gcc
: Assembler messages:
:5148: Error: symbol `fstatat64' is already defined
:5185: Error: symbol `fsta
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal |minor
Keywords||diagnostic
ht
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-05-13 17:02 ---
Related to PR 43630.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-05-13 16:58
---
I have a revised patch that handles default integer and negative error codes.
It is testing and I will submit when I get an opportunity.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43851
--- Comment #1 from iains at gcc dot gnu dot org 2010-05-13 16:48 ---
Created an attachment (id=20659)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20659&action=view)
fix PR44120
this is a quick-fix,
FWIW we seem to be getting an ever-increasing number of #ifdef OBJCPLUS - I
won
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-13 16:45 ---
Patch:
http://gcc.gnu.org/ml/fortran/2010-05/msg00135.html
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #4 from steve dot chapel at a2pg dot com 2010-05-13 16:28
---
:)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38404
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-13 16:21
---
On it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedT
--- Comment #3 from andi-gcc at firstfloor dot org 2010-05-13 16:16 ---
I think it should describe multiple lines.
next is expected to iterate through loops, not skip them.
If I wanted to skip I would use "until"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44113
I imagine this will affect all targets.
dpd -I../libdecnumber/GCC/gcc-live-trunk/gcc/objc/objc-act.c \
-o objcp/objcp-act.o
/GCC/gcc-live-trunk/gcc/objc/objc-act.c: In function
build_typed_selector_reference:
/GCC/gcc-live-trunk/gcc/objc/objc-act.c:2709:8: error: too few argu
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:36 ---
Well, you step to the next line-number and only lines #5 are remaining, so
I think you just get what you asked for. I don't know if we could (or should)
signal to gdb that there are multiple lines #5 now. Jakub?
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:33 ---
We throw away DECL_DEBUG_EXPR in free-lang-data (and do not try to stream it).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:31 ---
This is know. GCC does not use LFS and thus fails. A patch to fix that
was once applied but broke AIX and thus was reverted.
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44112
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-13 15:27 ---
The PRE change again.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-05-13 15:27 ---
Confirmed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
--with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r159348-install
--program-prefix=r159348- --enable-languages=c,c++
Thread model: posix
gcc version 4.6.0 20100513 (experimental) (GCC)
[reg...@gamow tmp413]$ current-gcc -O2 -c small.c
small.c: In function 'fu
--- Comment #1 from zsojka at seznam dot cz 2010-05-13 15:11 ---
Created an attachment (id=20658)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20658&action=view)
reduced testcase
$ g++ pr44118.C
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44118
Tested revisions:
r159305 - crash (after pr34491 fix)
4.5 r158978 - crash
4.4 r158133 - crash
Compiler output:
$ /mnt/svn/gcc-trunk/binary-159305-lto-fortran/bin/g++ testcase.C
testcase.C:2:30: error: template parameters not used in partial specialization:
testcase.C:2:30: error: ''
testca
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-13 14:55 ---
When removing the NULL initialization in comment #3, the dump shows:
static struct .class.parent.p this = {.$data=0B};
Zeroing the $data pointer is probably not needed without NULL initialization.
With NULL initia
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:49 ---
Fix posted: http://gcc.gnu.org/ml/gcc-patches/2010-05/msg00960.html
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-13 14:47 ---
(In reply to comment #0)
> fff.f90:26:0: internal compiler error: in gfc_conv_structure, at
> fortran/trans-expr.c:4390
It turns out this ICE is actually due to the NULL() initialization of the class
pointer and has n
--- Comment #1 from amonakov at gcc dot gnu dot org 2010-05-13 14:46
---
> r...@matylda1: /mnt/data/kasparek# LC_ALL=C gcc -o test.o test-10356.c
> cc1: error: test-10356.c: Value too large for defined data type
> The first this I need to help with is how to
> check if the code that ca
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:44 ---
*** Bug 44117 has been marked as a duplicate of this bug. ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-13 14:44 ---
*** This bug has been marked as a duplicate of 44110 ***
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-05-13 14:37 ---
Depends on both -O3 and -g:
i...@linux-fd1f:/tmp> gfortran proc_ptr_23.f90
i...@linux-fd1f:/tmp> gfortran -O3 proc_ptr_23.f90
i...@linux-fd1f:/tmp> gfortran -O3 -g proc_ptr_23.f90
/tmp/ccALU2k0.o:(.debug_info+0x81):
On multi-TB storage array with XFS filesystem I have to enable 64bit inodes
recently (inode64 mount option). Having test.c with:
int main(void){
return 0;
}
compiles fine for one file, but if i copy it to another one (several times till
it got the right inode number) it produces:
r...@matylda1
FAIL: gfortran.dg/proc_ptr_23.f90 -O3 -g (test for excess errors)
WARNING: gfortran.dg/proc_ptr_23.f90 -O3 -g compilation failed to produce
executable
FAIL: gfortran.dg/proc_ptr_25.f90 -O3 -g (test for excess errors)
WARNING: gfortran.dg/proc_ptr_25.f90 -O3 -g compilation failed to produce
--- Comment #1 from jakub at gcc dot gnu dot org 2010-05-13 14:34 ---
Buggy gdb, see http://bugzilla.redhat.com/589467
The lto/whopr issues are LTO bugs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44115
--- Comment #10 from hjl dot tools at gmail dot com 2010-05-13 14:31
---
*** Bug 44114 has been marked as a duplicate of this bug. ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-13 14:31 ---
*** This bug has been marked as a duplicate of 43924 ***
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--
--- Comment #9 from hjl dot tools at gmail dot com 2010-05-13 14:31 ---
Reopen. This bug report has more info than PR 44114.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-13 14:28
---
Indeed, fixed for 4.6.0 by the patch which fixed PR34491.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
--- Comment #1 from dominiq at lps dot ens dot fr 2010-05-13 14:25 ---
*** Bug 43924 has been marked as a duplicate of this bug. ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
-
--- Comment #8 from dominiq at lps dot ens dot fr 2010-05-13 14:25 ---
*** This bug has been marked as a duplicate of 44114 ***
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-13 14:24 ---
Subject: Bug 44104
Author: jakub
Date: Thu May 13 14:24:36 2010
New Revision: 159367
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159367
Log:
PR debug/44104
* dwarf2out.c (modified_type_die):
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22
---
*** Bug 44091 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #13 from pinskia at gcc dot gnu dot org 2010-05-13 14:22
---
*** This bug has been marked as a duplicate of 38644 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 149 matches
Mail list logo
