--- Comment #1 from deligonul at gmail dot com 2010-05-01 06:52 ---
Created an attachment (id=20524)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20524&action=view)
Temp output from gcc
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43953
The code below causes an ICE in GCC 4.5.0. It compiles fine in GCC 4.4.3.
$ g++ -save-temps -o crash crash.cpp
crash.cpp: In function âint main()â:
crash.cpp:23:22: internal compiler error: in dependent_type_p, at cp/pt.c:17404
Please submit a full bug report, ...
Output of g++ -v:
Using b
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end |c++
Ever Con
--- Comment #8 from hjl dot tools at gmail dot com 2010-05-01 03:13 ---
A run-time testcase:
[...@gnu-34 483.xalancbmk]$ cat x.cc
extern "C" void abort (void);
class Foo
{
public:
Foo (void) : xxx (1) {};
const int xxx;
};
Foo *
bar ()
{
return new Foo;
}
int
main ()
{
Foo *p
--- Comment #7 from hjl dot tools at gmail dot com 2010-05-01 03:10 ---
Here is a testcase:
[...@gnu-34 483.xalancbmk]$ cat x.cc
class Foo
{
public:
Foo (void);
const int xxx;
};
Foo *
bar ()
{
return new Foo;
}
[...@gnu-34 483.xalancbmk]$ /export/gnu/import/rrs/158918/usr/bin/g+
--- Comment #1 from corsepiu at gcc dot gnu dot org 2010-05-01 01:55
---
Created an attachment (id=20523)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20523&action=view)
Define _MACHINE_ANSI_H if target defines _I386_ANSI_H_ ||
defined(_X86_64_ANSI_H_
This patch tries to to over
Building GCC-4.5.0 for targets i?86-netbsdelf5* and amd64-netbsdelf5*
chokes on issues related to ptrdiff_t and further types from stddef.h.
>From what I gather, the cause is these targets not providing
_ANSI_H nor _MACHINE_ANSI_H in their header but them using
_I386_ANSI_H_ rsp. _X86_64_ANSI_H
--- Comment #6 from hjl dot tools at gmail dot com 2010-05-01 01:15 ---
(In reply to comment #5)
> (In reply to comment #3)
> > is the cause.
>
> What happens if you revert the build_new_1 part? That is not part of the
> changelog.
>
It works since my patch in comment #4 is the minim
--- Comment #14 from jason at gcc dot gnu dot org 2010-05-01 00:58 ---
Looks like my patch for 43075 didn't fix things completely.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from mrs at gcc dot gnu dot org 2010-05-01 00:33 ---
Thanks.
--
mrs at gcc dot gnu dot org changed:
What|Removed |Added
CC|mikestump at co
--- Comment #13 from mrs at gcc dot gnu dot org 2010-05-01 00:32 ---
Subject: Bug 32052
Author: mrs
Date: Sat May 1 00:32:13 2010
New Revision: 158958
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158958
Log:
2010-04-30 Iain Sandoe
PR objc++/32052
* objc-ac
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-05-01 00:24 ---
(In reply to comment #3)
> is the cause.
What happens if you revert the build_new_1 part? That is not part of the
changelog.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43951
--- Comment #4 from hjl dot tools at gmail dot com 2010-05-01 00:23 ---
This patch:
---
Index: cp/init.c
===
--- cp/init.c (revision 158918)
+++ cp/init.c (working copy)
@@ -1911,7 +1911,7 @@ build_new_1 (VEC(tree,gc) *
--- Comment #3 from hjl dot tools at gmail dot com 2010-05-01 00:15 ---
Revision 158918:
http://gcc.gnu.org/ml/gcc-cvs/2010-04/msg01025.html
is the cause.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43951
--- Comment #2 from hjl dot tools at gmail dot com 2010-05-01 00:13 ---
StylesheetExecutionContextDefault.cpp is miscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43951
--- Comment #3 from sje at cup dot hp dot com 2010-04-30 22:55 ---
I've built GCC on IA64 HP-UX 11.31, but never in 64 bit mode. I build in 32
bit mode (the default for GCC and HP C) and I haven't seen this problem. I'll
try
building in 64 bit mode to see if I can reproduce the problem
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-04-30 22:13 ---
(In reply to comment #5)
> The compiler shouldn't crash anyway. But with a new version this problem
> should
> be solved too, isn't it?
It should be. 4.5.0 was released by now. Could you check again?
--
dfranke
--- Comment #1 from hjl dot tools at gmail dot com 2010-04-30 22:00 ---
Revision 158918:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43951
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
-
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-04-30 21:54 ---
See PR41359 for another use of SET_EXPR_LOCATION.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41827
--- Comment #6 from jakub at gcc dot gnu dot org 2010-04-30 21:34 ---
It IMHO shouldn't be DW_TAG_pointer_type, it is not a C style pointer.
DW_TAG_array_type is what is emitted and what is listed in DWARF3/4 examples
for Fortran code with POINTER variables. And current GCC certainly em
--- Comment #5 from jason at gcc dot gnu dot org 2010-04-30 21:25 ---
Subject: Bug 43868
Author: jason
Date: Fri Apr 30 21:24:27 2010
New Revision: 158952
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158952
Log:
PR c++/43868
* cxx-pretty-print.c (pp_cxx_type_sp
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-04-30 21:11 ---
Has this been WAITING for 18 months now?
Any news? :)
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
---
--
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 #22 from dfranke at gcc dot gnu dot org 2010-04-30 21:02
---
Proposed patch:
http://gcc.gnu.org/ml/fortran/2010-04/msg00328.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--- Comment #4 from jason at gcc dot gnu dot org 2010-04-30 20:48 ---
Subject: Bug 43868
Author: jason
Date: Fri Apr 30 20:48:12 2010
New Revision: 158947
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158947
Log:
PR c++/43868
* cxx-pretty-print.c (pp_cxx_decl_sp
--- Comment #6 from svfuerst at gmail dot com 2010-04-30 20:30 ---
For posterity, I might as well note that with the sbb added on the end we don't
need the initial mov instruction if we do some register renaming. This leaves
the, hopefully optimal this time, five-instruction fragment as
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43951
On Linux/x86-64, revision 158930 miscompiled 483.xalancbmk in SPEC CPU 2006
with -O2 -ffast-math:
Running 483.xalancbmk ref base o2 default
483.xalancbmk: copy #0 non-zero return code (rc=0, signal=11)
Error with
'/export/gnu/import/svn/gcc-test/spec/2006/x86_64/spec/bin/specinvoke -E -d
/expo
--- Comment #1 from jakub at gcc dot gnu dot org 2010-04-30 19:20 ---
Making the FE preserve the case would be very hard. So, just posted a patch
to use DW_ID_down_case for Fortran.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from kargl at gcc dot gnu dot org 2010-04-30 19:04 ---
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01922.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43592
--- Comment #5 from ubizjak at gmail dot com 2010-04-30 19:00 ---
(In reply to comment #4)
> Argh, the sar trick doesn't work when the number is negative and even. Sorry
> about the extra noise.
>
> This leaves as the best code:
> mov%rsi,%rdx
> shr$0x3f,%rdx
> lea(%rdi,%rd
--
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 #8 from jakub at gcc dot gnu dot org 2010-04-30 18:56 ---
Fixed for 4.4+.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSI
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-04-30 18:53
---
Subject: Bug 43879
Author: rguenth
Date: Fri Apr 30 18:52:44 2010
New Revision: 158945
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158945
Log:
2010-04-30 Richard Guenther
PR tree-optimizatio
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-30 18:42 ---
Subject: Bug 43893
Author: jakub
Date: Fri Apr 30 18:41:42 2010
New Revision: 158942
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158942
Log:
PR c/43893
* c-omp.c (c_finish_omp_for): Handle a
--- Comment #5 from burnus at gcc dot gnu dot org 2010-04-30 18:36 ---
Close as FIXED.
With the other issues (passing as actual arguments) I will deal - but not as
part of this PR. See PR 18918 for the general coarray tracking.
--
burnus at gcc dot gnu dot org changed:
W
--- Comment #25 from burnus at gcc dot gnu dot org 2010-04-30 18:31 ---
Subject: Bug 18918
Author: burnus
Date: Fri Apr 30 18:30:53 2010
New Revision: 158941
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158941
Log:
2010-04-30 Tobias Burnus mbur...@net-b.de>
PR fortr
--- Comment #4 from burnus at gcc dot gnu dot org 2010-04-30 18:31 ---
Subject: Bug 43931
Author: burnus
Date: Fri Apr 30 18:30:53 2010
New Revision: 158941
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158941
Log:
2010-04-30 Tobias Burnus mbur...@net-b.de>
PR fortra
--- Comment #9 from jakub at gcc dot gnu dot org 2010-04-30 18:26 ---
Should be fixed for 4.4.5.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known t
Fortran currently lowercases all the identifiers for DWARF.
In such case it should set DW_AT_identifier_case = DW_ID_down_case.
GDB currently assumes DW_ID_down_case for DW_LANG_Fortran* which is incorrect,
consumer should always default to DW_ID_case_sensitive according to DWARF4.
Fortran should
--- Comment #2 from kargl at gcc dot gnu dot org 2010-04-30 18:09 ---
I have a patch.
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unas
--- Comment #4 from jb at gcc dot gnu dot org 2010-04-30 18:02 ---
Some more experimentation, on different hardware, reveals that the relative
performance of "rep stos" vs. loop depends heavily on the size of the object to
set, the optimization options (loop unrolling etc.), and presumab
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2010-04-30 17:31
---
Looking into it.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from kargl at gcc dot gnu dot org 2010-04-30 17:28 ---
(In reply to comment #4)
> (In reply to comment #3)
> > Any chance to convert the code in comment #1 into a testcase?
> >
> > laptop:kargl[205] grep "already present" *c
> > laptop:kargl[206] grep "already" *c
> > lap
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-30 17:25 ---
Confirmed. VRP is stupid and does
Visiting statement:
index_4 = i_21 % 3;
Found new range for index_4: VARYING
Yet another missed optimization.
--
rguenth at gcc dot gnu dot org changed:
What|
--- Comment #4 from burnus at gcc dot gnu dot org 2010-04-30 17:17 ---
(In reply to comment #3)
> Any chance to convert the code in comment #1 into a testcase?
>
> laptop:kargl[205] grep "already present" *c
> laptop:kargl[206] grep "already" *c
> laptop:kargl[207] grep "Entity" *c
I t
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-04-30 17:12
---
(In reply to comment #18)
> > As far as I understand this use statement causes GFortran to read in the
> > bytecode from the .mod file and combine the files again to a single
> > translation unit. So this split is
--- Comment #4 from iains at gcc dot gnu dot org 2010-04-30 16:57 ---
(In reply to comment #3)
> see:
> http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00585.html
> and:
> http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00131.html
I think this should be cleared now - by:
http://gcc.gnu.org/ml
--- Comment #3 from kargl at gcc dot gnu dot org 2010-04-30 16:53 ---
(In reply to comment #2)
> Found the latest version (thanks Bill!):
> http://j3-fortran.org/doc/year/10/10-006A.txt
>
> It clearly states that it is invalid.
>
> (In reply to comment #1)
> > Fortran 2003 (j3/04-007)
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-30 16:43 ---
Found the latest version (thanks Bill!):
http://j3-fortran.org/doc/year/10/10-006A.txt
It clearly states that it is invalid.
(In reply to comment #1)
> Fortran 2003 (j3/04-007) only has C1209 in "Annex D":
Actually
--- Comment #4 from svfuerst at gmail dot com 2010-04-30 16:33 ---
Argh, the sar trick doesn't work when the number is negative and even. Sorry
about the extra noise.
This leaves as the best code:
mov%rsi,%rdx
shr$0x3f,%rdx
lea(%rdi,%rdx,1),%rax
and$0x1,%eax
sub%rdx
--- Comment #2 from viriketo at gmail dot com 2010-04-30 16:32 ---
(In reply to comment #1)
> Err, so what is the configuration and what are you trying to do ? It sounds
> like you are trying to do a profiled bootstrap. Is that the case ?
Sorry, I thought that the information I pasted
$ cat test.cpp
void f();
int c[3];
int result;
struct Vector {
static int get(int i) {
if (i >= 3)
f();
return c[i];
}
};
void g()
{
for (int i = 0; i < 3; ++i) {
const int index = i % 3;
result = Vector::get(index) + Vector::get(index);
--- Comment #3 from svfuerst at gmail dot com 2010-04-30 16:12 ---
Oops, you are right. The 128 bit version needs an extra sbb on the end with
that code. (For some reason I was missreading the shr as a sar.):
mov%rsi,%rdx
shr$0x3f,%rdx
lea(%rdi,%rdx,1),%rax
and$0x1,%ea
--- Comment #1 from burnus at gcc dot gnu dot org 2010-04-30 16:02 ---
Maybe this is wrong. The edit ends with:
Remove C1209 from 12.3.2.1.
HISTORY: 04-406m170 Submitted
04-406r1 m170 Passed J3 meeting
05-146m171 Passed J3 letter ballot #10
Fortran 2003 (j
--- Comment #11 from redi at gcc dot gnu dot org 2010-04-30 15:58 ---
(In reply to comment #9)
> My report says that gcc violates
> that standard, because it gratuitously dumps POSIX names into my global space.
And once again, my response said "yes, I know but WONTFIX"
> Of course, I m
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2010-04-30
15:54 ---
Subject: Re: FAIL: libgomp.fortran/reduction3.f90
> Does this still fail ? Recent testresults don't show this failure in
> libgomp.
It's not failing on trunk. Will recheck 4.4 and 4.5.
Dave
--
ht
--- Comment #18 from dominiq at lps dot ens dot fr 2010-04-30 15:53 ---
> As far as I understand this use statement causes GFortran to read in the
> bytecode from the .mod file and combine the files again to a single
> translation unit. So this split is in fact not a split.
>From my ve
See http://www.j3-fortran.org/doc/meeting/172/05-006ar1.txt Item F03/0019
QUESTION 1:
Does the following program conform to the 2003 standard?
program P
interface X
subroutine S ( A )
integer :: A
end subroutine S
procedure S
end interface X
end program P
AN
--- Comment #4 from paolo dot carlini at oracle dot com 2010-04-30 15:41
---
> I am aware constexpr is not fully supported,
To be clear: officially, is not supported *at all*. If Jason told you that we
want to remember this specific detail in Bugzilla, fine, of course. You may
want to
--- Comment #2 from davek at gcc dot gnu dot org 2010-04-30 15:30 ---
Posted: http://gcc.gnu.org/ml/gcc-patches/2010-04/msg01899.html
--
davek at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from jv244 at cam dot ac dot uk 2010-04-30 15:26 ---
in this case the Fortran bits depend on PR40011
--
jv244 at cam dot ac dot uk changed:
What|Removed |Added
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-04-30 15:17
---
(In reply to comment #15)
> > ... without -fwhole-file. But all IPA optimizations rely on that, so it's
> > critical that -fwhole-file is enabled.
>
> -fwhole-file works only at the file level, i.e., if proc_ptr_
--- Comment #15 from dominiq at lps dot ens dot fr 2010-04-30 14:51 ---
> ... without -fwhole-file. But all IPA optimizations rely on that, so it's
> critical that -fwhole-file is enabled.
-fwhole-file works only at the file level, i.e., if proc_ptr_comp_12.f90 is
split as:
[macbook]
--- Comment #10 from joseph at codesourcery dot com 2010-04-30 14:42
---
Subject: Re: ostream includes unistd.h outside namespace
std, polluting
On Fri, 30 Apr 2010, igodard at pacbell dot net wrote:
> namespace that has not been opened by "using". My report says that gcc
> violate
--- Comment #6 from pault at gcc dot gnu dot org 2010-04-30 14:33 ---
(In reply to comment #0)
> Another OOP problem found by Salvatore.
>
> Jim Xia confirms that NAG f95 gives the correct result, cf.
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e18d0434c46598
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
CC||dfranke at gcc dot gnu dot
|
--- Comment #9 from igodard at pacbell dot net 2010-04-30 14:24 ---
This is not a fault of POSIX, because I'm *not* using POSIX. I'm using C++
ostream. Because I'm not using POSIX I expect to be able to declare (for
example) "int open = 0;" without a problem - "open" is not a reserved ke
--- Comment #6 from david at rothlis dot net 2010-04-30 14:01 ---
OK, thanks for the explanation!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943
--- Comment #14 from rguenth at gcc dot gnu dot org 2010-04-30 13:57
---
Indeed all proc_ptr_* execution FAILs are fixed with -fwhole-program. The
frontend does not properly unify decls for example in proc_ptr_comp_12.f90
for
testObj%test => returnMat
vs.
function returnMat( a,
to/43946
* passes.c (init_optimization_passes): Move pass_ipa_free_lang_data
first after all lowering passes.
* gcc.dg/lto/20100430-1_0.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/lto/20100430-1_0.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/passes.c
trunk/gcc/t
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-04-30 13:23 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #12 from steven at gcc dot gnu dot org 2010-04-30 13:22 ---
Iain, perhaps you should request to be confirmed as ObjC maintainer.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32052
--- Comment #3 from public at alisdairm dot net 2010-04-30 13:15 ---
Subject: Re: [C++0x] constexpr should allow declaration without a
definition
I am aware constexpr is not fully supported, and checked with Jason before
filing this issue.
We believe that constexpr should cur
--- Comment #2 from paolo dot carlini at oracle dot com 2010-04-30 12:57
---
Really, constexpr are *not* available yet, it seems definitely too early to
file PRs (in retrospect, I think we should not have committed those parser
bits, are causing a lot of counfusion :(
--
http://gcc
--- Comment #1 from redi at gcc dot gnu dot org 2010-04-30 12:55 ---
I think "support" is putting it a bit strongly :)
There is some code in place to recognise the keyword, that's about it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43947
GCC 4.5 has early support for constexpr, which syntax checks code but does not
support use in a constant expression.
The following code should be allowed, but fails as GCC currently requires the
in initial declaration also be a definition:
constexpr auto five() -> int;
inline constexpr auto five(
--- Comment #7 from jakub at gcc dot gnu dot org 2010-04-30 12:10 ---
The #c6 patch bootstrapped/regtested fine on x86_64-linux and i686-linux.
In --enable-checking=yes,rtl build number of variables with DW_AT_location grew
by 105 (excluding df-problems.o) in x86-64 cc1plus and by 98 in
--- Comment #21 from rguenth at gcc dot gnu dot org 2010-04-30 12:06
---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNE
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-04-30 12:02 ---
Mine, I have a patch.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Assig
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-04-30 11:43 ---
"Proper" testcase:
static void
expand_stmt_with_iterators_1 (void)
{
extern void expand_expr_stmt (void);
expand_expr_stmt ();
}
void
iterator_expand (void)
{
expand_stmt_with_iterators_1 ();
}
--
http://
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-04-30 11:42 ---
Without -fprofile-arcs we never output the decl copy (so it probably gets
lost).
So this seems to be a latent problem with early inlining?
At least the inlining before profiling sees
{ Scope block #0
extern void
--- Comment #20 from jakub at gcc dot gnu dot org 2010-04-30 11:31 ---
Subject: Bug 43942
Author: jakub
Date: Fri Apr 30 11:30:52 2010
New Revision: 158932
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158932
Log:
PR debug/43942
* tree.c (auto_var_in_fn_p): Retu
--- Comment #5 from redi at gcc dot gnu dot org 2010-04-30 11:26 ---
The point being that it's undefined behaviour to /return/ from such a function,
not to /write/ such a function.
If the programmer guarantees the "missing return" will never happen then
there's no error.
I was wrong to
--- Comment #19 from jakub at gcc dot gnu dot org 2010-04-30 11:24 ---
Subject: Bug 43942
Author: jakub
Date: Fri Apr 30 11:24:16 2010
New Revision: 158931
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158931
Log:
PR debug/43942
* tree.c (auto_var_in_fn_p): Retu
--- Comment #4 from redi at gcc dot gnu dot org 2010-04-30 11:22 ---
(In reply to comment #3)
> > a function with a missing return is valid
>
> I just can't reconcile that with the following line from the C++ standard: "It
> is now invalid to return (explicitly or implicitly) from a fun
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-04-30 11:19 ---
We end up with a 2nd FUNCTION_DECL "for debug info" which does not have
an assembler name set. Created by:
Run till exit from #0 0x00bbcb87 in copy_node_stat (
node=0x75adcb00) at /space/rguenther/
--- Comment #2 from hubicka at ucw dot cz 2010-04-30 10:57 ---
Subject: Re: SPEC2000 GCC fails to build with
-fprofile-generate -O2 -ffast-math -flto -fwhole-program
This smeells like notice_global_symbol issue again that computes assembler name
on random first symbol in th
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-04-30 10:44 ---
We fail the DECL_ASSEMBLER_NAME_SET_P (decl) check. The function declaration
in question is an implicit one at the point of its use (which means that
we likely do not get a cgraph node for it at LTO dump time).
Tes
--- Comment #18 from jakub at gcc dot gnu dot org 2010-04-30 10:24 ---
All patches bootstrapped/regtested on x86_64-linux and i686-linux,
unfortunately patch3 had slightly negative impact on debuginfo quality (about
4000 variables
in rtl checking cc1plus lost DW_AT_location attribute).
--- Comment #3 from ro at gcc dot gnu dot org 2010-04-30 10:15 ---
This only happens when using GCC with Sun as, GNU as with either Sun ld or GNU
ld
is fine. While gas follows the ELF gABI and sets SHT_INIT_ARRAY on an
.init_array
section, Sun as does not, and I see no easy workaround.
--- Comment #13 from rguenth at gcc dot gnu dot org 2010-04-30 10:06
---
I can now successfully bootstrap with -O2 -fipa-pta but lto1 seems to be
miscompiled (all LTO tests ICE).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43879
We get:
unit size
align 32 symtab 0 alias set -1 canonical type 0x77ed0498
precision 32 min max
pointer_to_this >
QI
size
unit size
align 8 symtab 0 alias set -1 canonical type 0x76e370a8>
addressable public exte
--- Comment #4 from cfriedt at visible-assets dot com 2010-04-30 09:54
---
(In reply to comment #0)
> Please consider this patch. It adds support for obtaining file basename via
> __FILE_BASENAME__.
Please do!
What would also be really nice would be to have similar functionality for
--- Comment #8 from redi at gcc dot gnu dot org 2010-04-30 09:51 ---
> I guess I'm still not being clear. I'm not using *any* of those names; I'm not
If you're not using the names why do you care?
> using C; I'm not using POSIX. I'm only using ostream, which is a plain old C++
> librar
cal/gnu46
--enable-languages=c,c++,fortran,lto --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20100430 (experimental) (GCC)
[sfili...@donald bug15]$ gfortran -o testd15 testd15.f03
testd15.f03:73:0: internal compiler error: in gfc_add_component_ref, at
fortran/expr.c:703
Please submit
--- Comment #4 from sfilippone at uniroma2 dot it 2010-04-30 09:42 ---
Created an attachment (id=20522)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20522&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #3 from sfilippone at uniroma2 dot it 2010-04-30 09:41 ---
(In reply to comment #1)
> (In reply to comment #0)
> > Another OOP problem found by Salvatore.
> >
> >
> Whoa, you beat me in opening the bug!
>
If I modify the source code as in the next attachment, I get an ICE
--- Comment #6 from charlet at gcc dot gnu dot org 2010-04-30 09:36 ---
The bug is in your manual build procedure (the patch to
s-finimp.adb is a kludge that would only hide the wrong build procedure) which
is
bypassing the gnat toolset normal operations.
I would suggest using stand alo
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-30 09:35 ---
"4.5.7.3 Type-bound procedure overriding" (F2008 FDIS):
"If a specific type-bound procedure specified in a type definition has the same
binding name as a type-bound procedure from the parent type then the binding
spe
1 - 100 of 190 matches
Mail list logo
