--- Comment #2 from aoliva at gcc dot gnu dot org 2009-10-07 07:23 ---
Thanks for the bug report, confirmed, looking into it.
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
--
aoliva at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last rec
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-07 07:37 ---
Created an attachment (id=18733)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18733&action=view)
gcc45-pr41445.patch
Updated patch that actually passed bootstrap. Unfortunately it regresses many
gcc.dg/cpp/ te
--- Comment #5 from burnus at gcc dot gnu dot org 2009-10-07 08:02 ---
More from the thread.
Richard Maine wrote:
The Note appears to have been removed from f2003, but see
F95 Note 5.6. Apparently it was the interface body case I was recalling
rather than the module procedure cas
--- Comment #2 from burnus at gcc dot gnu dot org 2009-10-07 08:09 ---
Actually, according to a note (cf. PR 41603 comment 5) the interface actually
could be valid - as long it is not used.
While invoking the function directly is properly rejected, e.g. the following
c = assumed_len(5
The following is properly rejected but the error message is bogus:
Error: Character-valued internal function 'assumed_len' at (1) must not be
assumed length
I tried to find an internal function, but all I see is a module procedure. (For
internal functions, assumed-length result values are also in
--- Comment #4 from jakub at gcc dot gnu dot org 2009-10-07 08:19 ---
Created an attachment (id=18734)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18734&action=view)
gcc45-pr41445.patch
An updated patch that actually fixes all cpp.exp regressions except 2 matches
in spacing1.c,
--- Comment #10 from burnus at gcc dot gnu dot org 2009-10-07 08:20 ---
(In reply to comment #8)
> Created an attachment (id=18732)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18732&action=view) [edit]
> Potential patch to fix pr40737
>
> Here is a patch from Adhemerval Zanella
--- Comment #1 from chris dot smith at st dot com 2009-10-07 08:33 ---
Did anyone ever find a solution to this? I'm seeing exactly the same effect
with gcc 4.3.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38766
--- Comment #1 from redi at gcc dot gnu dot org 2009-10-07 08:46 ---
The code is not valid, you need to change the line with the error to:
dbLeft.template detectFileChange<3>();
--
redi at gcc dot gnu dot org changed:
What|Removed |Added
-
In the following testcase:
inline int f(int *a)
{
return *a;
}
main()
{
int b=1;
return f(&b);
}
We ought to be able to track that value of "b" is 1. However we do not:
main ()
{
:
# DEBUG a => &b
return 1;
}
--
Summary: Variables promoted to Gimple registers by aliasing a
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-10-07 09:29 ---
Huh? You just cited the errors you got. Use -pedantic if you want to be
warned about $ in identifiers.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-10-07 09:33 ---
Raphael, can you look into this?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from zhnmju123 at gmx dot de 2009-10-07 09:33 ---
Thanks for the fast reply! I had tried compilation with VC++ 2008 and there it
worked, so I thought it would be valid.
Maybe a more expressive error message could help. In this shortened example the
error message is ... wel
--- Comment #4 from dominiq at lps dot ens dot fr 2009-10-07 09:45 ---
The fix in revision 152513 has been regtested without regression. Closing as
fixed.
--
dominiq at lps dot ens dot fr changed:
What|Removed |Added
---
--- Comment #3 from redi at gcc dot gnu dot org 2009-10-07 09:48 ---
(In reply to comment #2)
> Thanks for the fast reply! I had tried compilation with VC++ 2008 and there it
> worked, so I thought it would be valid.
You should be wary of using VC++ to determine if code is valid, it's n
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-07 09:50 ---
I am looking into this.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Ass
Seen with a lot of GNUstep applications:
gcc AppController.m -c \
-MMD -MP -DGNUSTEP -DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1
-DGNU_RUNTIME=1 -DGNUSTEP_BASE_LIBRARY=1 -D_REENTRANT -fPIC -g -Wall -DDEBUG
-fno-omit-frame-pointer -DGSWARN -DGSDIAGNOSE -Wno-import -O2
-fno-strict-ali
--- Comment #1 from doko at ubuntu dot com 2009-10-07 09:52 ---
Created an attachment (id=18735)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18735&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
--- Comment #2 from doko at ubuntu dot com 2009-10-07 09:53 ---
Created an attachment (id=18736)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18736&action=view)
assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
--- Comment #3 from doko at ubuntu dot com 2009-10-07 09:53 ---
Created an attachment (id=18737)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18737&action=view)
preprocessed source
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
--- Comment #4 from doko at ubuntu dot com 2009-10-07 09:54 ---
Created an attachment (id=18738)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18738&action=view)
assembler file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
--- Comment #4 from chris dot hhodges at gmail dot com 2009-10-07 10:23
---
(In reply to comment #3)
> Please let us know if you fix this and/or you are still stuck.
>
Yes. I've got this fixed now!
gcc now fully compiled.
Many thanks for the pointer to the __gmp_get_memory_functions
--- Comment #1 from domob at gcc dot gnu dot org 2009-10-07 10:32 ---
Confirmed, I'll investigate what we can do here (and look at similar cases).
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from rob1weld at aol dot com 2009-10-07 11:21 ---
(In reply to comment #1)
> Yes GPU libraries would be nice but this needs a lot of work to begin with.
> First you have to support the GPUs. This also amounts to doubling the
> support.
> If you really want them, since
--- Comment #1 from hubicka at ucw dot cz 2009-10-07 11:26 ---
Subject: Re: New: Variables promoted to Gimple registers by aliasing are not
getting debug statements.
> We ought to be able to track that value of "b" is 1. However we do not:
> main ()
> {
> :
> # DEBUG a => &b
Note
--- Comment #4 from zhnmju123 at gmx dot de 2009-10-07 12:30 ---
This seems to be the member template analogon to cases where "typename" is
needed for nested types. Thanks for the detailed explanation!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41614
The following invalid program is currently accepted:
type t1
integer :: comp
class(t1),pointer :: cc
end type
class(t1) :: x! invalid: must be dummy, allocatable or pointer
x%comp = 3
print *,x%comp
end
Removing the line which defines the class pointer component 'cc' causes the
--- Comment #5 from jakub at gcc dot gnu dot org 2009-10-07 12:57 ---
This doesn't even compile, you forgot NXConstStr.h stuff.
When it is added, it compiles just fine, at least on x86_64-linux and
i686-linux, no assembler errors.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41617
While doing a bunch of experiments with randomly constructed sets of
optimization flags, I ran into the following compilation error while trying to
build SPEC CPU2000's 252.eon:
internal compiler error: in insert_save, at caller-save.c:1122
The problem occurs during compilation of various of the
--- Comment #1 from kenneth dot hoste at elis dot ugent dot be 2009-10-07
13:13 ---
Created an attachment (id=18739)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18739&action=view)
reduced testcase for this bug
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41619
On Linux/i686, revision 152526 failed to bootstrap:
[...@gnu-29 libjava]$ /export/gnu/import/svn/gcc-test/bld/./gcc/xgcc
-shared-libgcc -B/export/gnu/import/svn/gcc-test/bld/./gcc -nostdinc++
-L/export/gnu/import/svn/gcc-test/bld/i686-pc-linux-gnu/libstdc++-v3/src
-L/export/gnu/import/svn/gcc-test
--- Comment #34 from jakub at gcc dot gnu dot org 2009-10-07 13:35 ---
Linker bug, so closing. Workaround also exists, use a non-buggy linker, or use
non-obsolete crt files.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from hjl dot tools at gmail dot com 2009-10-07 13:35 ---
It may be caused by revision 152520:
http://gcc.gnu.org/ml/gcc-cvs/2009-10/msg00169.htm
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #2 from hudson at comp dot ufla dot br 2009-10-07 13:47 ---
Ok, but this isn't a warning, it's an *error*. Concordant to specification
ANSI, it's not acceptable. Even -pedantic option must to give an error, no?
Anyway, thanks by reply!
--
http://gcc.gnu.org/bugzilla/sho
--- Comment #3 from jakub at gcc dot gnu dot org 2009-10-07 13:58 ---
You are looking for -pedantic-errors I guess.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41610
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
GCC target triplet||i686-pc-linux-gnu
Target Milestone|--- |4.5
--- Comment #2 from domob at gcc dot gnu dot org 2009-10-07 14:04 ---
At least now this can be considered fully implemented, I think.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from domob at gcc dot gnu dot org 2009-10-07 14:09 ---
This is still happening with current gfortran trunk, though the ICE is now in
[/tmp]# gfortran-dev test.f90
test.f90: In function 'myfortran_error':
test.f90:8:0: internal compiler error: in fold_convert_loc, at
fold
--- Comment #1 from domob at gcc dot gnu dot org 2009-10-07 14:10 ---
I'll try to find some better formulation for the manual.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from domob at gcc dot gnu dot org 2009-10-07 14:12 ---
As another note, I already did the mistake of indexing a string as str(n)
instead of str(n:n) for single characters multiple times; and IIRC there's not
much useful a diagnostic in any case, so maybe I can improve ther
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-07 14:57 ---
It's mostly
a) target specific builtin types and decls that do not get fixed up
b) LTO (or rather generic) builtin functions and types not get fixed up
c) the tree.c local canonical type machinery that isn't gi
seen with builds from the 4.4 branch, compiler configured biarch, defaulting to
32bit; these testcase don't fail when the testsuite is run with -m64. Not seen
on trunk 20090803.
gcc is configured with: --with-pkgversion='Debian 4.4.1-5'
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr -
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-10-07
15:09 ---
Subject: Re: [4.5 Regression] Internal error compiling fortran/intrinsic.c
> > I see this has -g and this sounds like PR41343 where cc1 is killed because
> > the
> > compiler runs out of VM . Could you tr
--- Comment #6 from doko at ubuntu dot com 2009-10-07 15:15 ---
Created an attachment (id=18740)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18740&action=view)
preprocessed source
regenerated with objc/NXConstStr.h included.
--
doko at ubuntu dot com changed:
Wha
The following program:
#include
#include
int main()
{
std::unordered_set set;
std::string key("foo");
for (int i=0; i<1000; ++i) {
set.count(key);
}
return 0;
}
(if compiled without optimizations) makes 1000 calls to the std::string copy
constructor (according to profi
--- Comment #1 from jbytheway at gmail dot com 2009-10-07 15:45 ---
Created an attachment (id=18741)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18741&action=view)
Patch providing proof-of-concept implementation
I attach a patch implementing this change on svn HEAD. It doesn't
--- Comment #2 from redi at gcc dot gnu dot org 2009-10-07 16:07 ---
(In reply to comment #1)
> but I am fairly sure I've done the wrong thing to the linker script
> (gnu.ver); I don't really understand the linker script, so it was rather
> monkey-see-monkey-do.
I think the commented ou
--- Comment #4 from hudson at comp dot ufla dot br 2009-10-07 16:23 ---
Oh, yeah! I'm sorry!
I'll take care in the next time...
Thanks a lot!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41610
--- Comment #3 from paolo dot carlini at oracle dot com 2009-10-07 16:42
---
Nope. This library follows the ISO Standards ad TRs, and both the current CD
and TR1 mandates by value. I can try to raise the issue in Santa Cruz by
certainly we can't just change the implementation like this.
--- Comment #4 from paolo dot carlini at oracle dot com 2009-10-07 16:51
---
Two very general comments: 1- Certainly, you can't change old exports like
this, you can only *add* exports at later version numbers; 2- If you mean to
contribute more to the library (that would be great!) I wo
--- Comment #9 from bkoz at gcc dot gnu dot org 2009-10-07 16:56 ---
Beyond caret diagnostics there is also range info for the diagnostic location.
See:
http://clang.llvm.org/diagnostics.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
--- Comment #10 from manu at gcc dot gnu dot org 2009-10-07 17:06 ---
(In reply to comment #9)
> Beyond caret diagnostics there is also range info for the diagnostic location.
See the patch and thread at
http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00459.html
and the requested patch:
--- Comment #15 from vmakarov at gcc dot gnu dot org 2009-10-07 17:18
---
Subject: Bug 22072
Author: vmakarov
Date: Wed Oct 7 17:18:38 2009
New Revision: 152533
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152533
Log:
2009-10-07 Vladimir Makarov
PR middle-end/220
--- Comment #2 from jason at gcc dot gnu dot org 2009-10-07 17:54 ---
Yep, reverting that patch fixes libjava build. The patch incorrectly makes us
emit the abstract pre-cloning constructor.
--
jason at gcc dot gnu dot org changed:
What|Removed |A
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org
|dot org
--- Comment #10 from davek at gcc dot gnu dot org 2009-10-07 17:55 ---
(In reply to comment #9)
> Fixed at revision 152511.
>
My tests (r.152512) have now run far enough to confirm that all the new FAILs
are fixed. Thanks Danny!
--
davek at gcc dot gnu dot org changed:
--- Comment #2 from domob at gcc dot gnu dot org 2009-10-07 18:13 ---
Subject: Bug 41615
Author: domob
Date: Wed Oct 7 18:13:28 2009
New Revision: 152534
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152534
Log:
2009-10-07 Daniel Kraft
PR fortran/41615
* re
--- Comment #3 from domob at gcc dot gnu dot org 2009-10-07 18:15 ---
Fixed on trunk, now the message really prints "module procedure" for module
procedures.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #11 from jason at gcc dot gnu dot org 2009-10-07 18:31 ---
(In reply to comment #10)
> http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00459.html
That's a vasprintf patch, I don't see the connection.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985
Internal compiler error reported with target code with linux gcc 4.* series
compilers.
Tried: 4.1.2, 4.2.2, 4.2.4, 4.3.4. All fail.
Compiles fine in 3.4+.
--
Summary: ICE: emit_move_insn at expr.c 3162 when compiling
template code.
Product: gcc
--- Comment #1 from marvin dot decker at gmail dot com 2009-10-07 18:37
---
Created an attachment (id=18742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18742&action=view)
Precompiled source demonstrating error with 4.*
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41623
Nested functions in C are a serious misfeature, for any number of reasons (some
of which are even in the manual). They should be something a project should be
able to ban the use of at the language level, without forcing a switch to
strict non-gnu mode.
Also, unlike most g89 language features, th
--- Comment #3 from jason at gcc dot gnu dot org 2009-10-07 18:56 ---
Subject: Bug 41038
Author: jason
Date: Wed Oct 7 18:56:28 2009
New Revision: 152536
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152536
Log:
PR c++/41038
* tree.c (build_qualified_name): Cal
--- Comment #3 from jason at gcc dot gnu dot org 2009-10-07 18:56 ---
Subject: Bug 39863
Author: jason
Date: Wed Oct 7 18:56:39 2009
New Revision: 152537
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152537
Log:
PR c++/39863
* pt.c (tsubst_pack_expansion): Don'
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-10-07 19:00 ---
I don't think they are a misfeature at all. Ada for an example actually
requires nested functions even with the reasons we mention in the manual, that
is trampolines and such. Fortran also has nested functions.
No
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-10-07 19:03 ---
Confirmed. Reduced testcase:
#include
#include
template< class Iter, class Aggregator >
inline typename Aggregator::value_type
aggregate( Iter first, Iter second, Aggregator p_arg ) {
};
template< class A, clas
--- Comment #4 from jason at gcc dot gnu dot org 2009-10-07 19:32 ---
Subject: Bug 39863
Author: jason
Date: Wed Oct 7 19:31:56 2009
New Revision: 152538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152538
Log:
PR c++/39863
* pt.c (tsubst_pack_expansion): Don'
--- Comment #4 from jason at gcc dot gnu dot org 2009-10-07 19:32 ---
Subject: Bug 41038
Author: jason
Date: Wed Oct 7 19:31:56 2009
New Revision: 152538
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152538
Log:
PR c++/39863
* pt.c (tsubst_pack_expansion): Don'
--- Comment #5 from jason at gcc dot gnu dot org 2009-10-07 19:32 ---
Fixed for 4.4.2 and 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #5 from jason at gcc dot gnu dot org 2009-10-07 19:33 ---
Fixed for 4.4.2 and 4.5.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #1 from jason at gcc dot gnu dot org 2009-10-07 19:36 ---
Fixed for 4.5 (a few weeks ago).
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from jason at gcc dot gnu dot org 2009-10-07 19:45 ---
Neither 4.4.1 nor 4.5 try to call the copy constructor in your example; I
believe I fixed this issue in 4.4.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from jason at gcc dot gnu dot org 2009-10-07 19:50 ---
This was fixed long ago.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
St
--- Comment #35 from andreast at gcc dot gnu dot org 2009-10-07 19:54
---
Seems like powerpc-*-freebsd* is now also affected.
I have the -O1 patch in testing.
The newer binutils option is a nop since FreeBSD (has to) stay(s) on binutils
2.15.
--
http://gcc.gnu.org/bugzilla/show_bug
--- Comment #30 from potswa at mac dot com 2009-10-07 19:57 ---
The FSF receptionist says that the lawyer seems to have taken an unannounced
vacation this week. It's now three weeks since I requested the forms (and since
he confirmed my request). What is the timeframe we're shooting for?
system hang due to no-ending memory allocation when compiling this code
--
Summary: no-ending memory allocation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
As
--- Comment #1 from denis dot onischenko at gmail dot com 2009-10-07 20:25
---
Created an attachment (id=18743)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18743&action=view)
preprocessed file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41625
--- Comment #31 from paolo dot carlini at oracle dot com 2009-10-07 20:25
---
4.5.0 still seems a realistic target to me. I would suggest you using the time
it takes for the paperwork to complete (unfortunately, it *always* takes a lot
of time) to figure out a *minimal*, completely trus
--- Comment #2 from denis dot onischenko at gmail dot com 2009-10-07 20:27
---
Created an attachment (id=18744)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18744&action=view)
console output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41625
--- Comment #15 from davek at gcc dot gnu dot org 2009-10-07 20:33 ---
Created an attachment (id=18745)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18745&action=view)
global log
(In reply to comment #14)
> Subject: Re: Can't build libgomp without
> --enable-languages=fortran
>
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-10-07 20:51 ---
Likely a dup of PR41343
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
BugsThisDe
GCC does not bootstrap on powerpc64. It fails in the 2nd stage, when it links
build/gensupport.o. On the powerpc, the statements:
static struct obstack obstack;
struct obstack *rtl_obstack = &obstack;
On the powerpc generate a reference to an unknown external 'obstack', while on
the x86_64, it
--- Comment #1 from meissner at gcc dot gnu dot org 2009-10-07 21:14
---
Created an attachment (id=18746)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18746&action=view)
Simplified test case that fails on the powerpc.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41626
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu dot
|
--- Comment #12 from manu at gcc dot gnu dot org 2009-10-07 21:25 ---
(In reply to comment #11)
> (In reply to comment #10)
> > http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00459.html
>
> That's a vasprintf patch, I don't see the connection.
>
Ops, bad first link. This is the correct:
--- Comment #1 from jason at gcc dot gnu dot org 2009-10-07 21:27 ---
This is core issue 873,
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#873
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #18 from rguenth at gcc dot gnu dot org 2009-10-07 21:32
---
*** Bug 41625 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-10-07 21:32 ---
It is.
*** This bug has been marked as a duplicate of 41343 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-07 21:50 ---
This can be fixed by:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (Revision 152525)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -1465,7 +1465,7 @
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-07 21:58 ---
The fix:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (Revision 152525)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -3751,7 +3751,8 @@ gfc_match_d
--- Comment #2 from meissner at gcc dot gnu dot org 2009-10-07 22:00
---
Subversion revision 152520 is the revision that breaks this.
The change in question is:
009-10-07 Jan Hubicka
* lto-symtab.c (lto_cgraph_replace_node): Assert that inline clones has
no address
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-10-07 22:25 ---
This testcase works at -O0 but fails at -O1.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-10-07 22:34 ---
Reverting just the varpool.c file back to what it was, allows this testcase to
work.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41626
--- Comment #36 from amodra at bigpond dot net dot au 2009-10-07 22:35
---
Andreas, there is no way this bug can be fixed 100% in gcc, except perhaps if
you are willing to compile -static. Source and/or compiler fixes only work to
the extent that they limit code+data size to less than
--- Comment #12 from jsm28 at gcc dot gnu dot org 2009-10-07 22:36 ---
Testing a patch.
--
jsm28 at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|un
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-10-07 22:37 ---
This part is what is causing it:
! /* When reading back varpool at LTO time, we re-construct the queue in
order
! to have "needed" list right by inserting all needed nodes into
varpool.
!We how
--- Comment #11 from dh458 at oakapple dot net 2009-10-07 22:42 ---
(In reply to comment #10)
> > Here is a patch from Adhemerval Zanella from our IBM LTC Performance team,
> > that "fixes" the problem for me and bootstraps (powerpc64-linux) and
> > regtests with no regressions. Can so
Using a (patched) 4.4.1 gofortran on linux/x86, try to compile the attached
tcommon.f90
I get
gfortran /tmp/tcommon.f90
/tmp/tcommon.f90: In function 'tf_ad_splitting_driver_plane':
/tmp/tcommon.f90:109: internal compiler error: Segmentation fault
This was incidentally uncovered while trying to
1 - 100 of 110 matches
Mail list logo
